ExMinerSOF: minerando informações excepcionais do Stackoverflow

Texto

(1)Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra Departamento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação Mestrado Acadêmico em Sistemas e Computação. ExMinerSOF: Minerando Informações Excepcionais do StackOverflow. Teresa do Carmo Barrêto Fernandes. Natal-RN Junho de 2017.

(2) Teresa do Carmo Barrêto Fernandes. ExMinerSOF: Minerando Informações Excepcionais do StackOverflow. Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito para a obtenção do grau de Mestre em Sistemas e Computação. Linha de pesquisa: Engenharia de Software. Orientador. Profa. Dra. Roberta de Souza Coelho. PPgSC – Programa de Pós-Graduação em Sistemas e Computação DIMAp – Departamento de Informática e Matemática Aplicada CCET – Centro de Ciências Exatas e da Terra UFRN – Universidade Federal do Rio Grande do Norte. Natal-RN Junho de 2017.

(3) Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Especializada do Centro de Ciências Exatas e da Terra – CCET. Fernandes, Teresa do Carmo Barrêto. ExMinerSOF: Minerando Informações Excepcionais do Stackoverflow / Teresa do Carmo Barrêto Fernandes. – Natal, RN, 2017. 91f. : il. Orientadora: Profa. Dra. Roberta de Souza Coelho. Dissertação (mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Programa de Pós-Graduação em Sistemas e Computação.. 1. Engenharia de software. 2. Stackoverflow. 3. Stack trace. 4. Exceção. 5. Documentação de API. I. Coelho, Roberta de Souza. II. Título. RN/UF/BSE-CCET. CDU 004.41.

(4)

(5) Dedico este trabalho aos meus professores, das salas de aula e da vida..

(6) Agradecimentos Aos meus pais e às minhas irmãs pelo incentivo nos estudos e pela lição de vida que me passam diariamente. Aos professores do DIMAp/UFRN, em especial, a professora Roberta Coelho, pela paciência nas orientações e incentivos que tornaram possível a concretização deste trabalho. Aos colegas de laboratório (LETs/UFRN) pela troca de conhecimento e contribuições. À empresa ESIG Software & Consultoria, na qual trabalho, pelo incentivo ao possibilitar cursar o mestrado em concomitância. Finalmente, agradeço à Deus pela oportunidade que me proporcionou uma experiência de crescimento profissional e pessoal. Muito Obrigada!.

(7) O que prevemos raramente ocorre; o que menos esperamos geralmente acontece. Benjamin Disraeli.

(8) ExMinerSOF: Minerando Informações Excepcionais do StackOverflow. Autora: Teresa do Carmo Barrêto Fernandes Orientadora: Profa. Dra. Roberta de Souza Coelho. Resumo Exceções não capturadas (do inglês: uncaught) não são cenários excepcionais nas aplicações Java atuais. Eles são, na verdade, uma das principais causas de falha das aplicações Java - que podem originar-se de erros de programação (e.g., acesso a referências nulas); falhas no hardware ou em APIs utilizadas. Essas exceções uncaught resultam em stack traces que são frequentemente usados pelos desenvolvedores como fonte de informações para a depuração. Atualmente, essa informação é frequentemente usada pelos desenvolvedores em mecanismos de busca ou sites de perguntas e respostas (do inglês: Question and Answer - Q&A) para tentar compreender melhor a causa do crash e assim poder resolvêlo. Este estudo fez a mineração de stack traces incluídas nas perguntas e respostas do StackOverflow (SOF). O objetivo deste estudo foi: (i) identificar características das stack traces mineradas do SOF e (ii) investigar como tais informações podem ser usadas para evitar exceções uncaught durante o desenvolvimento de software. Neste estudo, 121.253 stack traces foram extraídas e analisadas em combinação com inspeções de postagens do SOF. Também é proposta a ferramenta ExMinerSOF, que alerta o desenvolvedor sobre as exceções que podem ser potencialmente sinalizadas por um método de API. Essas informações são descobertas aplicando uma estratégia de mineração apresentada neste trabalho. Ao fazê-lo, a ferramenta permite que o desenvolvedor evite falhas com base em falhas relatadas por outros desenvolvedores. Palavras-chave: Stackoverflow, stack trace, exceção, documentação de API..

(9) ExMinerSOF: Mining Exceptional Information from StackOverflow. Author: Teresa do Carmo Barrêto Fernandes Supervisor: Profa. Dra. Roberta de Souza Coelho. Abstract Uncaught exceptions are not an exceptional sce- nario in current Java applications. They are actually one of the main causes of applications crashes, which can originate from programming errors on the application itself (null pointer dereferences); faults in underlying hardware or re-used APIs. Such uncaught exceptions result in exception stack traces that are often used by developers as a source of information for debugging. Currently, this information is ofttimes used by developers on search engines or Question and Answer sites while the developer tries to: better understand the cause of the crash and solve it. This study mined the exception stack traces embedded on StackOverflow (SOF) questions and answers. The goal of this work was to two-fold: to identify characteristics of stack traces mined from SOF and to investigate how such information can be used to prevent uncaught exceptions during software development. Overall 121.253 exception stack traces were extracted and analyzed in combination with Q&A inspections. Hence, this study proposes ExMinerSOF tool, which alerts the developer about the exceptions that can be potentially signaled by an API method but are not part of the API documentation - and was discovered by applying a mining strategy in SOF repository. Doing so, the tool enable the developer to prevent faults based on failures reported by the crowd. Keywords: Stackoverflow, stack trace, exception, API documentation..

(10) Lista de figuras 1. Hierarquia de herança da classe Throwable . . . . . . . . . . . . . . . .. p. 22. 2. Exemplo de trecho de código de tratamento de exceção em Java . . . .. p. 23. 3. Exemplo da estrutura de stack traces da linguagem Java . . . . . . . .. p. 25. 4. O processo do estudo com os passos da mineração de stack traces, a análise dessas stack traces e a ferramenta proposta. . . . . . . . . . . .. 5. Zoom da Figura 4 que ilustra os passos da extração, identificação e armazenamento de stack traces. . . . . . . . . . . . . . . . . . . . . . . .. 6. p. 28. p. 29. Exemplo de formato de arquivo XML que contém postagens do StackOverflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 30. 7. Identificação dos elementos de uma stack trace Java.. p. 32. 8. Diagrama de entidade relacionamento das entidades criadas para repre-. . . . . . . . . . .. sentar uma stack trace do Java. . . . . . . . . . . . . . . . . . . . . . .. p. 34. 9. Cálculo da Precisão e Cobertura. . . . . . . . . . . . . . . . . . . . . .. p. 35. 10. Exemplo de dois blocos de stack traces que foram identificados pelo algoritmo de extração como sendo apenas uma única stack. . . . . . . . .. 11. p. 36. Exemplo de stack trace que não foi corretamente identificada pelo algoritmo de extração por conter texto de log do sistema. . . . . . . . . . .. p. 37. 12. Zoom da Figura 4 que ilustra os passos de análise das stacks extraídas.. p. 41. 13. Ilustra o fluxo da ferramenta proposta. . . . . . . . . . . . . . . . . . .. p. 48. 14. Trecho de código para ilustrar a atuação do mecanismo de recomendação da ferramenta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. p. 51. Consulta manual com os campos para informar a sequencia de nomes de métodos (A) ou nome de exceção (B). Logo abaixo, a lista com o resultado das stack traces (C). . . . . . . . . . . . . . . . . . . . . . . .. p. 52.

(11) 16. Visualização da postagem do Stackoverflow integrada à ferramenta. . .. 17. Assistente de conteúdo customizado com uma lista de exceções (A) rela-. p. 53. cionadas com o termo em foco pelo cursor (A) que poderia corresponder a um ou mais nomes totalmente qualificados de métodos de uma stack trace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18. Visualização da lista de stack traces do par método-exceção selecionado no mecanismo proativo.. 19. p. 54. . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 54. Visualização dos marcadores que sinalizam as exceções descobertas para as classes importadas e chamadas de métodos. . . . . . . . . . . . . . .. p. 55. 20. Configuração da ferramenta de recomendações. . . . . . . . . . . . . . .. p. 55. 21. Distribuição de ocorrências no SOF dos métodos das APIs mais populares do Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22. Distribuição de ocorrências no SOF dos métodos das APIs mais populares do Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. p. 60. p. 60. Exemplo de stack trace com ocorrênca do método "javax.servlet.http.HttpServlet.service". p. 62.

(12) Lista de tabelas 1. Classes da expressão regular usada para identificação de stack traces do Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 31. 2. Total de postagens e de stack traces identificados na extração. . . . . .. p. 37. 3. Quantitativos dos métodos identificados em stack traces mineradas. . .. p. 38. 4. Quantidade de postagens e de stack traces identificados para cada tag. .. p. 39. 5. Os 10 primeiros pares de método-exceção da API Hibernate mais referenciados nas stack traces, discriminando o total de ocorrências e se a exceção está documentada ou não em seu respectivo método. Todos esses métodos são do pacote org.hibernate, na tabela ele foi substituído pelo símbolo[..]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. p. 43. Os 10 primeiros pares de método-exceção da API Spring mais referenciados nas stack traces, discriminando o total de ocorrências e se a exceção está documentada ou não em seu respectivo método. Todos esses métodos são do pacote org.springframework, na tabela ele foi substituído pelo símbolo[..]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. p. 45. Os 10 primeiros pares de método-exceção da API Android mais referenciados nas stack traces, discriminando o total de ocorrências e se a exceção está documentada ou não em seu respectivo método. Todos esses métodos são do pacote com.android, na tabela ele foi substituído pelo símbolo[..].. p. 46. 8. Top 10 métodos com maior número de ocorrências em postagens do SOF. p. 61. 9. Top 10 métodos ordenados pela quantidade de exceções diferentes em ocorrências do SOF. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 10. Top 10 métodos ordenados pela quantidade de exceções diferentes em ocorrências do SOF, considerando o padrão "regra de três"[20]. . . . . .. 11. p. 62. p. 63. Classificação das APIs quanto a existência de exceções documentadas e a ocorrências de pares método-exceção em postagens do SOF. . . . . .. p. 64.

(13) 12. Comparativo entre ferramentas encontradas na literatura que extraem postagens do Stackoverflow provendo informações ao desenvolvedor que o auxiliam nas atividades. . . . . . . . . . . . . . . . . . . . . . . . . .. p. 69. 13. Classes de expressões regulares para identificação de stack traces Java.. p. 81. 13. Classes de expressões regulares para identificação de stack traces Java.. p. 82. 14. 100 APIs do Java mais populares do Repositório Central do Maven. . .. p. 83. 14. 100 APIs do Java mais populares do Repositório Central do Maven. . .. p. 84. 14. 100 APIs do Java mais populares do Repositório Central do Maven. . .. p. 85. 14. 100 APIs do Java mais populares do Repositório Central do Maven. . .. p. 86. 14. 100 APIs do Java mais populares do Repositório Central do Maven. . .. p. 87. 14. 100 APIs do Java mais populares do Repositório Central do Maven. . .. p. 88. 14. 100 APIs do Java mais populares do Repositório Central do Maven. . .. p. 89. 14. 100 APIs do Java mais populares do Repositório Central do Maven. . .. p. 90.

(14) Lista de algoritmos 1. Algoritmo usado para identificação de stack traces a partir do arquivo XML com as postagens do SOF. . . . . . . . . . . . . . . . . . . . . . .. p. 33.

(15) Sumário. 1 Introdução. p. 16. 1.1. Problema e Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 16. 1.2. Limitações de Abordagens Existentes . . . . . . . . . . . . . . . . . . .. p. 17. 1.3. Objetivos e Solução Proposta . . . . . . . . . . . . . . . . . . . . . . .. p. 18. 1.4. Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 19. 1.5. Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . .. p. 19. 2 Fundamentação Teórica. p. 21. 2.1. Tratamento de Exceção . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 21. 2.2. Exceções em Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 22. 2.3. Interface Excepcional . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 23. 2.3.1. Boas Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 24. 2.4. Stack Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 25. 2.5. Serviços de Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 26. 2.5.1. O Stackoverflow . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 26. Sistemas de Recomendação . . . . . . . . . . . . . . . . . . . . . . . . .. p. 27. 2.6. 3 Minerando Stack Traces do StackOverflow. p. 28. 3.1. Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 28. 3.2. Extração das Postagens do Stackoverflow . . . . . . . . . . . . . . . . .. p. 29. 3.3. Identificação de Stack Traces . . . . . . . . . . . . . . . . . . . . . . . .. p. 30. 3.4. Armazenamento das Stack Traces . . . . . . . . . . . . . . . . . . . . .. p. 33.

(16) 3.5. 3.6. Avaliando o Algoritmo de Extração de Stack Traces . . . . . . . . . . .. p. 34. 3.5.1. Cálculo da Precisão . . . . . . . . . . . . . . . . . . . . . . . . .. p. 35. Análise de Dados Extraídos . . . . . . . . . . . . . . . . . . . . . . . .. p. 37. 3.6.1. Tags Mais Frequentes . . . . . . . . . . . . . . . . . . . . . . . .. p. 38. 3.6.2. Heurísticas Adotadas para Utilização da Base de Stacktraces Construída . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 39. Inspeção de Exceções das APIs Spring, Hibernate e Android . .. p. 40. 3.7. Pacote de Replicação do Estudo . . . . . . . . . . . . . . . . . . . . . .. p. 46. 3.8. Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 47. 3.6.3. 4 O Plug-in ExMinerSOF. p. 48. 4.1. Coleta de Dados: Usando a Base de Stack Traces. . . . . . . . . . . . .. p. 48. 4.2. Mecanismos de Recomendação: Interagindo com a Ferramenta . . . . .. p. 49. 4.2.1. Consulta Manual pelo Desenvolvedor . . . . . . . . . . . . . . .. p. 49. 4.2.2. Recomendação Proativa por Chamada de Método . . . . . . . .. p. 50. 4.2.3. Recomendação Proativa por Classe Importada . . . . . . . . . .. p. 51. Interface do Usuário: Visualizando as Recomendações . . . . . . . . . .. p. 52. 4.3.1. Visualização da Recomendação não Proativa . . . . . . . . . . .. p. 52. 4.3.2. Visualização da Recomendação Proativa . . . . . . . . . . . . .. p. 53. 4.3.3. Configurando a Ferramenta . . . . . . . . . . . . . . . . . . . .. p. 55. 4.4. Estudo Qualitativo Preliminar . . . . . . . . . . . . . . . . . . . . . . .. p. 56. 4.5. Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 57. 4.3. 5 Minerando a Interface Excepcional de APIs Populares: Um Estudo Exploratório. p. 58. 5.1. Escolha das APIs Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 58. 5.2. Questões de Pesquisa que Orientaram o Estudo . . . . . . . . . . . . .. p. 59.

(17) 5.2.1. O SOF auxiliou a descobrir novas exceções na interface excepcional dos métodos? . . . . . . . . . . . . . . . . . . . . . . . . .. 5.2.2. Quais foram os métodos que mais dispararam discussões relacionadas a exceções uncaught? . . . . . . . . . . . . . . . . . . . .. 5.2.3. p. 61. Existe alguma característica em comum entre os top 10 métodos com maior número de exceções disparadas? . . . . . . . . . . . .. 5.2.4. p. 59. p. 61. Das 100 APIs mais populares, qual a porcentagem de APIs que dispararam pelo menos uma discussão relacionada a exceções do SOF? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.2.5. p. 64. Dos pares método-exceção identificados através da ferramenta de análise estática, quantos foram citados em postagens do SOF? .. p. 64. 5.3. Replicação do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 64. 5.4. Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 65. 6 Trabalhos Relacionados. p. 66. 6.1. Uso e Análise de Informações de Stack Traces . . . . . . . . . . . . . .. p. 66. 6.2. Sistemas de Recomendação que Extraem Postagens do Stackoverflow .. p. 68. 7 Considerações Finais. p. 72. 7.1. Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 73. 7.2. Ameaças a Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 73. 7.3. Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 75. Referências. p. 77. Apêndice A -- Dados de Precisão e Cobertura da Extração de Dados. p. 81. Apêndice B -- APIs selecionadas para a análise da interface excepcional. p. 83.

(18) 16. 1. Introdução. 1.1. Problema e Motivação. Bibliotecas de software (APIs) têm sido muito utilizadas pelas aplicações como uma forma de redução do tempo e custo de desenvolvimento de software. Se por um lado o uso de APIs pode trazer benefícios, por outro lado estudos têm mostrado que, muitas vezes, as falhas que ocorrem em aplicações cliente são causadas: pelo uso inapropriado das APIs [36][19], por erros de programação da própria API [31], ou por exceções Runtime não documentadas que são lançadas pelos métodos da API [15][5][28]. Quando a documentação sobre as exceções Runtime lançadas por métodos de APIs é não existente ou está incompleta, o desenvolvedor, no pior dos casos, irá descobrir essas situações excepcionais apenas quando o sistema estiver em um ambiente de produção. Este é um cenário recorrente causado por defeitos no código do tratamento das exceções (i.e., exceções não capturadas - do inglês: uncaught exceptions) que são um dos principais responsáveis por crashes de sistemas Java [12]. Quando ocorre alguma falha em aplicações Java causada por uma exceção uncaught, a JVM imprime a stack trace no console ou em um arquivo de log. A informação contida nas stack traces geralmente são usadas pelos desenvolvedores em engenhos de busca ou sites de Perguntas e Respostas (do inglês: Question and Answer - Q&A) que procuram entender melhor a causa da falha e encontrar soluções para ela. Alternativamente, para descobrir as exceções Runtime que fluem a partir de um método de API, o desenvolvedor tem três opções: (i) procurar por exceções na documentação da API - que costuma ser incompleta [15]; ou (ii) inspecionar o código fonte da API, que é uma tarefa muito custosa, além de existir casos em que o código não está facilmente disponível; ou (iii) procurar por ferramentas de análise estática do fluxo de exceções - porém estas sofrem com as limitações inerentes à análise estática quando combinadas com características de linguagens modernas (e.g. herança, polimorfismo, chamadas virtuais e.

(19) 17. Reflection) que induzem a falsos positivos [30][28]. Nenhuma dessas opções, entretanto, se beneficia da informação disponível nos sites de Q&A. O Stackoverflow (SOF). 1. é um exemplo de serviços de pergunta e resposta mais uti-. lizados no momento. Os usuários compartilham experiências e conhecimento sobre vários temas, como também de assuntos relacionados a linguagens de programação, frameworks, bibliotecas, dentre outros. O conjunto de informações disponíveis nesse tipo de serviço tornou-se frequente em substituição às documentações de software [22].. 1.2. Limitações de Abordagens Existentes. Alguns sistemas de recomendação têm sido utilizados como forma de auxiliar o desenvolvedor quando ele se depara com uma uncaught exception. Estes sistemas visam extrair dados de serviços de perguntas e respostas e otimizar o tempo de desenvolvimento. Alguns deles, apesar de minerarem postagens do Stackoverflow, não analisam stack traces ou requerem a ocorrência de falha para que ocorra a recomendação. Treude e Robillard [33] utilizam aprendizado supervisionado para relacionar trechos de documentações com sentenças das postagens do Stackoverflow. Amintabar, Heydarnoori e Ghafa [1] propõem uma ferramenta que recomenda candidatos para solução de exceções que ocorrem em tempo de execução, minerando issues e commits do SourceForge e postagens do Stackoverflow. A ferramenta de Rahman, Yeasmin e Roy [25] explora várias fontes de dados (Google, Bing, Yahoo e Stackoverflow) e utiliza métricas de relevância e ranqueamento a partir do contexto da aplicação cliente, porém requer que uma falha ocorra para que seus dados sejam utilizados nas consulta às engines. Outros estudos também não mostram, por exemplo, a informação sobre as exceções que fluem em um dado método da aplicação ou API que esteja em uso. Isso pode contribuir para a perda da compreensão da recomendação, exigindo que o desenvolvedor interprete as postagens. Ponzanelli et al [23] desenvolveram a ferramenta SeaHawk que realiza recomendações baseadas na entrada informada pelo próprio desenvolvedor, como também no seu código fonte em edição na IDE. A ferramenta tem como fonte o arquivo Dump do Stackoverflow e permite que trechos de código das postagens sejam arrastados para o editor java da IDE e visualizados por outras pessoas que compartilham o repositório do projeto. Em outro estudo Ponzanelli [24] propõe a ferramenta Prompter que abrange mais postagens com o uso da API do SOF. Cordeiro, Antunes e Gomes [7] relatam so1. http://stackoverflow.com/tour.

(20) 18. bre a ferramenta que realiza a consulta baseada em uma entrada textual informada pelo desenvolvedor e pelo seu contexto atual na IDE, considerando as bibliotecas que utiliza e os artefatos que manipula. A ferramenta utiliza o Dump do Stackoverflow para extrair stack traces e trechos de código java. Em outro trabalho Cordeiro, Antunes e Gomes [6] propõem ferramenta semelhante, mas que além do contexto do código fonte em edição, também considera as stack traces geradas a partir de falhas na própria aplicação. Ambos estudos exploram a interface excepcional presentes nas postagens evidenciadas através das marcações de blocos de código.. 1.3. Objetivos e Solução Proposta. Como já falado anteriormente, as abordagens atuais não possuem recursos que possibilitem ao desenvolvedor procurar sobre as exceções que fluem por um dado método. Tendo em vista a utilidade das informações disponíveis do StackOverflow, por que não utilizar as informações sobre falhas de outros sistemas para prevenir que ocorra o mesmo com a aplicação sendo desenvolvida? Dessa forma, na ausência de uma documentação completa, o desenvolvedor poderia se beneficiar de informações postadas por outros desenvolvedores em sites Q&A. Com elas, o desenvolvedor pode tomar conhecimento sobre as exceções Runtime não documentadas que podem fluir dos métodos da API antes que tais exceções causem falhas (já que, em algum momento, causaram uma falha em outro sistema). As informações disponíveis em serviços Q&A, como o Stackoverflow, são denominadas de "crowd knowledge" [22]. É o conhecimento gerado a partir da escrita e leitura feita por várias pessoas. Como consequência, a documentação emerge sob a forma de perguntas e respostas que contêm exemplos de código e discussões sobre o uso de classes e métodos de APIs. Essa documentação é um esforço compartilhado por muitos, e mesmo se a contribuição for mínima, o resultado pode atingir uma cobertura elevada da funcionalidade da API que fica disponível para um grande público. Dessa forma, essas informações também tornam-se uma rica fonte de conteúdo composto de trechos de código e discussões que são ativamente vistos e utilizados por vários desenvolvedores. Tendo em vista os benefícios de utilizar o conhecimento do "crowd" para contribuir na prevenção de falhas nos sistemas, este trabalho objetiva: • Minerar informações sobre as interfaces excepcionais dos métodos de APIs a partir da análise de stack traces postadas no Stackoverflow ;.

(21) 19. • Identificar características comuns às stack traces mineradas; • Investigar como essa informação pode ser usada para prevenir exceções uncaught durante o desenvolvimento.. 1.4. Contribuições. Neste trabalho desenvolvemos um algoritmo que nos permitiu minerar stack traces a partir das postagens do StackOverflow no período entre Agosto/2008 e Setembro/2014. Obtivemos o total de 21.736.594 postagens (entre questões e respostas) das quais 121.253 stack traces foram identificadas. A partir dos dados minerados, realizamos um estudo empírico em que tivemos alguns resultados, como: • Considerando as tags das postagens que contem pelo menos uma stack trace: 42% estavam associados a tag Java, 9% a tag Android, 6% Hibernate e 5% ao Spring; • Exceções não documentadas foram a causa de 83% das stack traces relacionadas aos framework Hibernate e quase 100% das stack traces relacionadas ao Spring; • 213.635 métodos distintos apareceram em pelo menos uma stack trace do SOF; e 49.485 métodos distintos apareceram em pelo menos 3 stack traces do SOF. • Das 100 APIs Java mais populares do repositório central do Maven, 29 possuem ocorrências de seus métodos em postagens do SOF, porém em nenhuma delas as exceções estavam documentadas no Javadoc. Outra contribuição foi a criação da ferramenta ExMinerSOF, um plug-in do Eclipse que usa as informações incorporadas em stack traces mineradas para descobrir quais as exceções que podem fluir dos métodos de APIs. Um estudo de caso preliminar foi realizado no contexto de uma empresa de desenvolvimento de software, e resultados iniciais mostram que a ferramenta foi útil para alertar o desenvolvedor sobre as exceções potencialmente sinalizadas por métodos de APIs, mas que ainda pode ser evoluída com melhorias.. 1.5. Organização do Documento. O restante deste trabalho está organizado da seguinte como segue. O Capítulo 2 apresenta a fundamentação teórica, com os principais conceitos da abordagem proposta..

(22) 20. O Capítulo 3 apresenta o processo de mineração de stack traces. O Capítulo 4 descreve a ferramenta ExMinerSOF.O Capítulo 5 detalha o estudo exploratório realizado com os dados minerados. O Capítulo 6 cita os trabalhos relacionados. O Capítulo 7 apresenta as considerações finais com as contribuições, limitações e trabalhos futuros relacionados a este trabalho..

(23) 21. 2. Fundamentação Teórica. O objetivo desse capítulo é apresentar uma fundamentação dos principais conceitos para o entendimento do trabalho. Serão apresentados conceitos relacionados a tolerância a faltas e o tratamento de exceções (Seção 2.1), também, de forma específica, sobre exceções em Java (Seção 2.2), a documentação excepcional (Seção 2.3) e stack traces (Seção 2.4). Será falado sobre a ascendência da utilização dos serviços de Q&A (Seção 2.5) e sobre sistemas de recomendação (Seção 2.6).. 2.1. Tratamento de Exceção. Tolerância a faltas são técnicas que provêm aos sistemas a capacidade de continuar a dispor os seus serviços mesmo na ocorrência de falhas provenientes de faltas existentes no seu código fonte. No contexto de tolerância a faltas, vale salientar as diferenças entre falha, falta e erro. Uma falta ou defeito é algo que foi implementado de maneira errada em algum artefato do sistema, alterando o funcionamento padrão do sistema. O erro é um estado intermediário entre a falta e a falha, quando o trecho do artefato que contêm a falta é exercitado. A falha ocorre quando o serviço prestado pelo sistema não funciona como o esperado. A falha pode ser ou não provocada pela falta [4]. Essas técnicas são implementadas para tornar os sistemas mais confiáveis e um dos exemplos comumente utilizados em projetos desenvolvidos na linguagem Java, é o tratamento de exceções. O tratamento de exceções é uma das facilidades que a linguagem Java dispõe, como também é o caso de outras linguagens modernas de programação. Este recurso permite detectar e prevenir situações de falha de execução antecipadamente. As condições de falha podem ser modeladas em forma de exceções, para, quando necessário, ser realizado o devido tratamento, dando continuidade ou interrompendo a execução a fim de preservar a integridade do sistema. Há casos em que é preciso relançar uma exceção,.

(24) 22. por exemplo, para fazer o tratamento devido em outra camada do sistema. Por isso, ao realizar uma chamada a métodos, principalmente a métodos disponíveis em bibliotecas externas, é fundamental que o desenvolvedor conheça quais exceções podem ser lançadas a partir desta chamada. Dessa forma, previne-se as situações excepcionais que possam ocorrer durante a execução do programa.. 2.2. Exceções em Java. Em Java as exceções são objetos de tipos herdados de uma classe especial chamada Throwable (Figura 1). Apenas objetos dessa classe ou de suas classes derivadas podem ser gerados, propagados e capturados através do mecanismo de tratamento de exceções. A classe Throwable se subdivide nas classes Error e Exception. A classe Error representa os erros internos da linguagem ou erros da máquina virtual. A classe Exception representa os erros de programação. As exceções podem ser de dois tipos: checadas e não checadas. As checadas devem ser explicitamente tratadas ou propagadas. As não checadas não são obrigadas a serem lançadas ou tratadas. Alguns exemplos de exceções não checadas são as exceções devido a acesso a objetos nulos ("NullPointerException"), exceções devido a divisão por zero ("ArithmeticException") dentre outros.. Figura 1: Hierarquia de herança da classe Throwable. O tratamento de exceções em Java é apresentado no trecho de código da Figura 2. Um conjunto de instruções é colocado dentro de um bloco protegido (circundado pela.

(25) 23. palavra reservada "try" e um conjunto de abre e fecha chaves). Se dentro desse trecho de código uma exceção for lançada, o programa é interrompido na linha de código que gerou a exceção e tem o seu fluxo transferido para o trecho de código que fica circundado pela palavra reservada "catch" e um conjunto de abre e fecha chaves associado. Caso a exceção não seja esperada, a execução do código pula para o próximo "catch", se existir. Uma exceção pode ser lançada ou relançada através do comando "throw". A palavra reservada "throws", usada na assinatura do método, define quais as Exceções checadas que podem ser lançadas pelo método. Caso uma exceção não seja capturada em nenhum ponto da hierarquia de chamadas, ela pode ser propagada até o ponto de entrada do programa fazendo com que a execução seja interrompida de forma inesperada.. Figura 2: Exemplo de trecho de código de tratamento de exceção em Java. 2.3. Interface Excepcional. Ao realizar uma chamada à métodos de uma API, por exemplo, é preciso conhecer quais as situações excepcionais que podem passar a partir API para a aplicação cliente. Assim, o método chamados pode se precaver de situações que possam gerar falha no sistema. Por conta disso, algumas linguagens fornecem recursos que possibilitam associar a assinatura de um determinado método à uma lista de exceções que esse método pode lançar. Esse conceito é definido por Miller e Tripathi [21] como interface excepcional de um método. Na teoria, a interface de exceção deve fornecer informações completas e precisas para quem realizará a chamado do método. Porém, muitas das vezes, as linguagens, como Java, fornecem mecanismos que possibilitam contornar a definição da interface. Por exemplo, isso é possível ser feito utilizando as exceções não checadas, que não requer declaração na assinatura dos métodos. Por este motivo, podemos classificar dois tipos de especificação de exceção: (i) interface excepcional explicita e (ii) interface excepcional completa. A primeira refere-se às exceções presentes na assinatura do método, ou que esteja explicitamente declaradas. A segunda engloba todas exceções sinalizadas pelo método, incluindo exceções não checadas que não estão especificadas na assinatura do método..

(26) 24. 2.3.1. Boas Práticas. Joshua Bloch [3] e James Gosling [11] definem um conjunto de boas práticas com relação a utilização de exceções em sistemas Java. Dentre as práticas podemos citar as seguintes: • As exceções checadas devem ser usadas para representar condições recuperáveis, que devam ser contornadas. Ao confrontar o usuário da API com uma exceção checada, a API está forçando o cliente a lidar com a condição excepcional. O cliente pode explicitamente ignorar a exceção ou convertê-lo para outro tipo, arriscando a robustez do programa. • O erro representa uma condição irrecuperável que não deve ser tratada. Os erros devem resultar de falhas detectadas pelo ambiente de tempo de execução que indicam deficiências de recursos, falhas invariantes ou outras condições, das quais o programa não pode se recuperar. • Um método deve lançar exceções que definam com precisão a condição excepcional. Para isso, os desenvolvedores devem tentar reutilizar os tipos de exceção já definidos na API Java ou criar exceções específicas. Lançar tipos gerais, como "java.lang.Exception" ou um "java.lang.RuntimeException" é considerado má prática. • Todas as exceções explicitamente lançadas pelo código reutilizável devem ser documentadas. Para exceções checadas, isso já ocorre. Recomenda-se documentar exceções de tempo de execução que sejam explicitamente lançadas, usando uma declaração de "throws" na assinatura, ou usando a tag "@throws" no Javadoc. Através dessas boas práticas fica claro que a responsabilidade deve-se tanto ao projetista da API quanto do cliente que a utiliza. Com a exposição da interface excepcional, quem for realizar uma chamada ao método será capaz de preparar o seu código de forma antecipada, prevenindo-se das condições excepcionais que possam ocorrer durante a execução do sistema. Por outro lado, a incompletude ou imprecisão da definição da interface excepcional traz riscos de falha ao programa cliente. A omissão da declaração das exceções, dá brecha para que elas não sejam devidamente tratadas na aplicação. Não havendo o tratamento na continuação do fluxo da exceção, o sistema falhará e a execução do sistema poderá ser interrompida. Na ocorrência de falhas, são exibidas informações a cerca do fluxo excepcional que a ocasionou, denominado de stack trace..

(27) 25. 2.4. Stack Traces. As stack traces dispõem informações relevantes para a identificação de exceções e o seu relacionamento com os métodos inclusos no fluxo de exceção originado pelo defeito no código fonte. Uma vez que a exceção é lançada, em tempo de exceção, o sistema procura o manipulador de exceção mais próximo ( bloco "try-catch"). A exceção pode, por exemplo, ser propagada para o próximo manipulador usando o encapsulamento: uma exceção é capturada e envolvida em outra, que, por sua vez, pode ser lançada sem o uso de encapsulamento. Isso ocorre até que o sistema encontre um manipulador que realize o tratamento da exceção, ou, se não existir, o sistema pode ser interrompido, expondo ao usuário a falha que não pôde ser tratada. A Figura 3 ilustra um exemplo da estrutura das stack traces do Java. A parte inferior do rastreamento de pilha é a exceção raiz, que indica a primeira causa para a exceção lançada (neste caso, a ausência de memória). A parte superior do rastreamento de pilha indica o local da manifestação da exceção (que é o encapsulador).. Figura 3: Exemplo da estrutura de stack traces da linguagem Java. O fluxo de execução entre a exceção de raiz e o encapsulador pode incluir outros encapsuladores de exceção intermediários. Em todos os níveis, o sinalizador de exceção é o método que lançou a exceção, representada no rastreamento de pilha como a primeira chamada de método abaixo da declaração de exceção. Como pode ser visto na parte inferior do rastreamento de pilha, o método "constructNative()", que é definido na classe "java.lang.reflect.Constructor", falhou e lançou a exceção "java.lang.OutOfMemoryError". Esta é a exceção raiz, ou a causa principal. A parte superior da stack indica o local da manifestação da exceção. O fluxo entre a exceção raiz e a sua manifestação possui en-.

(28) 26. capsuladores intermediários. Em todos os níveis, o sinalizador de exceção é o método que lançou a exceção, representada no rastreamento de pilha como a primeira chamada de método abaixo da declaração de exceção.. 2.5. Serviços de Q&A. Os serviços de Questões e Respostas (do inglês: Question ans Answer - Q&A) são um exemplo nos quais os desenvolvedores de diferentes áreas e capacidades postam perguntas e respostas relativas a diversos projetos e linguagens. Dentre as postagens pode-se notar a presença de trechos de stack traces que representam a ocorrência de falhas de programas decorrentes da utilização de APIs, por exemplo, cuja solução pode servir para problemas semelhantes encontrados por outros desenvolvedores [32]. A utilização e compartilhamento desse tipo de informação nessas fontes de dados é denominado de crowd knowledge [23]. A utilização deste tipo de informação tem se tornado bastante frequente, em muitos casos sendo mais consultado do que as documentações formais do software. Isto tem ocorrido devido as documentações dos projetos estarem desatualizadas ou incompletas, além de ser difícil de relacionar as suas informações com o contexto do problema do desenvolvedor [18]. Isso faz com que o desenvolvedor perca tempo na procura da informação necessária para resolver o seu problema.. 2.5.1. O Stackoverflow. O Stackoverflow é um exemplo desse tipo de serviço disponível atualmente na internet. Ele é um popular site de perguntas e respostas voltado para a comunidade de programadores que faz parte da rede de sites Stack Exchange Q&A. Além do stackoverflow.com, a plataforma do Stack Exchange possui outros sites voltados para outras áreas que não a de programação. Podemos destacar o mathematics.com que é voltado aos estudantes de matemática e profissionais da área; o askubuntu.com que é voltado a usuários e desenvolvedores do Ubuntu; o http://serverfault.com voltado para administradores de sites e de rede; o http://tex.stackexchange.com que é voltado aos usuários de LaTex ; dentre outros serviços. Com o StackOverflow é possível acessar rapidamente o conhecimento sobre várias áreas da programação [34]. E ainda, pelo fato de ser uma plataforma que segue uma abordagem de perguntas e respostas, ela permite o compartilhamento de problemas e sugestões de soluções entre programadores. Isso pode ocorrer de forma independente da experiência.

(29) 27. do programador, do projeto em que esteja trabalhando ou da linguagem que trabalha, possibilitando uma maior diversidade das informações que o Stackoverflow disponibiliza.. 2.6. Sistemas de Recomendação. Como dito anteriormente, apesar da importante fonte de conhecimento que são os serviços Q&A, eles não estão integrados com o ambiente de desenvolvimento (IDE). Dessa forma, o desenvolvedor é forçado a deixar a sua IDE, interrompendo o fluxo de programação e reduzindo o seu foco na tarefa atual. Para reduzir este custo é necessário a utilização de ferramentas de apoio, como é o caso dos sistemas de recomendação [23]. Sistemas de software de recomendação auxiliam os desenvolvedores a obterem informações com base nos seus interesses e conforme o contexto no qual estão inseridos, seja sobre um artefato ou processo de software, por exemplo. Essas informações podem auxiliar aos desenvolvedores na tomada de decisões em situações complexas ou em que ele não tenha experiência, como na reutilização de código fonte para orientar mudanças de software [26]. Com o crescimento da complexidade dos projetos de software, é difícil para o desenvolvedor dominar o conhecimento mediante a variedade de conceitos, frameworks e bibliotecas envolvidas. Durante a fase de testes, por exemplo, é comum a ocorrência de exceções que originam falhas. As stack traces produzidas então são analisadas para identificar a falta e obter uma solução. Este é um cenário em que é bem vindo ao desenvolvedor a existência de recursos que forneçam pistas sobre possíveis soluções. Dessa forma, as recomendações evitariam o desperdício de tempo de desenvolvimento ao navegar na internet em busca de informações relevantes, que neste caso depende exclusivamente da capacidade do desenvolvedor..

(30) 28. 3. Minerando Stack Traces do StackOverflow. Neste capítulo será apresentado o processo de mineração de stack traces realizado neste trabalho, que consiste na extração (Seção 3.2), identificação (Seção 3.3) e armazenamento (Seção 3.4) de stack traces. Apresenta também as métricas utilizadas para validar o algoritmo de identificação de stack traces (Seção 3.5) e, ao final, uma análise da base obtida como resultado da mineração (Seção 3.6).. 3.1. Visão Geral. A Figura 4 apresenta os passos do processo desse estudo. Primeiro, nós mineramos as stack traces a partir das postagens do Stackoverflow (passos 1, 2, 3). Então, com essas informações armazenadas em um banco de dados, nós iniciamos uma análise (passos 4, 5, 6) do seu conteúdo comparando as exceções extraídas e a documentação dos métodos relacionados às stacks. Em seguida, também utilizando essa base de stack traces, nós construímos um plug-in para auxiliar os desenvolvedores. Ele será detalhado na Seção 4.. Figura 4: O processo do estudo com os passos da mineração de stack traces, a análise dessas stack traces e a ferramenta proposta..

(31) 29. Em relação a mineração das stack traces, ela foi realizada em três passos: a extração, a identificação e o armazenamentos das stack traces, como identificado na Figura 5. Cada passo será discutido nas seções seguintes.. Figura 5: Zoom da Figura 4 que ilustra os passos da extração, identificação e armazenamento de stack traces.. 3.2. Extração das Postagens do Stackoverflow. A fonte de dados utilizada foi o Stackoverflow, mais precisamente as suas postagens que são representadas através de perguntas e respostas. As postagens possuem vários dados para serem analisados, como a data de criação, o tipo de postagem (se é uma pergunta ou resposta), o seu conteúdo, as tags que foram marcadas, dentre outros. Utilizamos o Dump do Stack Exchange disponibilizado pelo Data Challenge do MSR1 , que compreende os dados registrados no período entre Agosto de 2008 até Setembro de 2014. Quando baixado e descompactado, o arquivo excede o tamanho de 25GB. O Dump contém todo o conteúdo gerado pelos usuários dos sites que fazem parte da plataforma do Stack Exchange, dentre eles o Stackoverflow, como visto na Seção 2.5.1. Este conteúdo representa postagens, usuários, votos, comentários, histórico de postagens e links de postagens registrados. O arquivo principal é compactado no formato 7-zip 2 e contém as informações organizadas de acordo com cada site. Para cada site há arquivos separados que organizam cada tipo de informação. Existe um arquivo para as postagens, outro arquivo para os comentários, e assim por diante. Finalmente, cada arquivo deste está no formato XML3 e possui os dados a respeito dos atributos da informação que representa. 1. http://2015.msrconf.org/challenge.php http://www.7-zip.org 3 http://www.w3.org/TR/REC-xml/ 2.

(32) 30. Neste estudo, como o interesse é a análise das postagens, nos ateremos a explicação do seu conteúdo. A estrutura do arquivo será explicada mais adiante. Para a leitura do arquivo XML, foi preciso conhecer a sua estrutura. Os arquivos que armazenam os dados de postagens, por exemplo, possuem o formato conforme pode ser visto na Figura 6. Nela está destacado os atributos das postagens. Cada postagem é representada por uma linha através da tag "row" que contem todas as propriedades que podem ser extraídas, tais como: identificador da postagem, representado pelo atributo "Id"; o tipo de postagem que identifica se a postagem é uma pergunta ou resposta, representado no arquivo pelo atributo "PostTypeId"; a data de criação da postagem, representado pelo atributo "CreationDate"; o conteúdo da postagem, representado pelo atributo "Body"; dentre outras.. Figura 6: Exemplo de formato de arquivo XML que contém postagens do StackOverflow.. Ao realizar a leitura do arquivo XML, foram identificadas 21.736.594 postagens (entre perguntas e respostas) contidas no Dump. Nessa abordagem, não há a preocupação de identificar as respostas de uma pergunta específica, já que cada linha representa uma postagem e o tipo da postagem pode ser identificado através de uma das propriedades da linha do arquivo XML, como dito anteriormente.. 3.3. Identificação de Stack Traces. A identificação das stack traces foi feita com base em expressões regulares, assim como outros estudos também as utilizam [5][15]..

(33) 31. A expressão regular foi criada e validada utilizando as próprias postagens e a documentação Java4 que especifica a estrutura das stack traces. A Tabela 1 ilustra a expressão regular utilizada na identificação de stack traces, bem como das classes auxiliares utilizadas na sua composição e criadas com base na documentação dos construtores de expressão regular do Java5 . Classe. Expressão Regular. stacktrace. exception ? (\\s+ at \\s+ (methodPath\$class\$)). exception. (([graph]*[blank]+|)([alnum.]+)(Exception| Error ))(.*). methodPath. [graph]*. class. (([graph]*.[lower]+):([digit]*))|([graph]*). graph. alnum. [alnum,punct] ` [! "#$%&´()*+,-./:;<=>?@[]_ ˆ {|} ] {alpha}{digit}. alnum. {alpha}{digit}. alpha. {lower}{upper}. lower. [a-z]. upper. [A-Z]. digit. [0-9]. blank. [\\t]. punct. Tabela 1: Classes da expressão regular usada para identificação de stack traces do Java.. Na Figura 7 pode-se identificar um exemplo de stack trace com destaque da composição dos frames. Facilmente, é possível distinguir a exceção do bloco principal, reconhecida pela presença da expressão "Exception" ou "Error". Essas palavras chaves são comumente usadas como nome de classes de exceção. O bloco também é composto por uma sequência de frames que iniciam com a expressão "at" seguida do caminho da classe que contém o método, o nome do método, o nome da classe e o número da linha da classe que originou a falha. Há casos em que não é possível identificar a linha da classe, como é o caso de falhas que ocorrem em método nativos. Antes de aplicar a expressão regular, o algoritmo faz um tratamento sob o conteúdo da postagem, removendo algumas tags que são inerentes às postagens do Stackoverflow. Por exemplo, a tag <code><code/> é ignorada, pois não faz parte da estrutura de stack traces e podem atrapalhar a análise. 4 5. http://docs.oracle.com/javase/7/docs/api/java/lang/Throwable.html http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html.

(34) 32. Figura 7: Identificação dos elementos de uma stack trace Java.. Foi levado em consideração que uma mesma postagem (pergunta ou resposta) pode conter mais de um bloco de frames. Todos eles são identificados pelo algoritmo implementado. Outra ressalva é sobre os blocos de causa, que possuem a expressão Caused by:. Como esses blocos têm a estrutura bem semelhante à dos demais stack traces, o algoritmo consegue identificá-los utilizando a mesma expressão regular mostrada anteriormente. Nesses casos, é realizada uma verificação a mais. Após identificar que o conteúdo de uma postagem contém uma stack trace, é verificado se a expressão Caused by: está presente na string. Em caso afirmativo, o stack trace é marcado como sendo um bloco de causa. Essa informação foi armazenada para que possa ser utilizada em análises posteriores, como na identificação de exceções que originam as falhas registradas nos relatórios. O algoritmo a seguir descreve o passo-a-passo utilizado na extração de stacktraces a partir do arquivo de Dump. Para cada linha do arquivo é recuperado o conteúdo correspondente a postagem do SOF. A partir dele é aplicado a expressão regular para identificar as stacks, podendo uma mesma postagem possuir mais de um bloco de stacktrace. Elas são armazenadas temporariamente em uma coleção. Ao final do arquivo, a coleção de stacktraces identificadas são persistidas na base de dados. Os passos de identificação e persistência das stacktraces serão detalhados nas seções seguintes..

(35) 33. Algoritmo 1 Algoritmo usado para identificação de stack traces a partir do arquivo XML com as postagens do SOF. 1: função minerarStacktraces(arquivoXM L) enquanto existeP roximaLinhaArquivo() faça. 2: 3:. linha ← recuperarLinha();. 4:. conteudoP ostagem ← recuperarConteudoP ostagem(linha);. 5:. stacktraceIdentif icada ← verdade;. 6:. listaStacktraces ← vazio;. 7:. enquanto stacktraceIdentif icada faça. 8:. stack ← aplicarExpressaoRegular(conteudoP ostagem);. 9:. se stack = vazio então stacktraceIdentif icada ← f also;. 10: 11:. fimSe. 12:. listaStacktraces.adicionar(stack);. 13:. fimEnquanto. 14:. salvarStacktraces(listaStacktraces); fimEnquanto. 15:. 16: fimFunção. 3.4. Armazenamento das Stack Traces. As stack traces identificadas ao longo da mineração são persistidas numa base de dados relacional. A base de stacks é composta por um conjunto de tabelas que correspondem as principais entidades/propriedades de uma stack trace: o bloco da stack trace, o frame, a exceção, os métodos da pilha de execução e a classe respectiva a cada método. A Figura 8 apresenta o diagrama de entidade e relacionamento da base de dados utilizada para armazenar as stack traces. A seguir descrevemos as principais entidades deste diagrama: • A entidade Stacktrace possui o identificador da resposta, caso a postagem na qual o stack trace foi identificado seja uma resposta (id_answer); o identificador da pergunta (id_pergunta), caso a postagem na qual o stack trace foi identificado seja uma pergunta; o conteúdo da postagem (content); uma flag que identifica o stack trace como um bloco de causa (is_causedby); a data em que o stack trace foi salvo no banco de extração de dados (creation_date); a data de criação da postagem no site fonte da extração (creation_date_post); as tags presentes na postagem (tags); além de um relacionamento com a entidade Exception (id_exception)..

(36) 34. Figura 8: Diagrama de entidade relacionamento das entidades criadas para representar uma stack trace do Java. • A entidade Exception possui a informação do nome da classe de exceção (name) e uma descrição que compreende todo a expressão da exceção (description). • A entidade Frame, que está relacionada com Stacktrace (id_stacktrace), possui a informação da linha da classe em que a falha ocorreu (file_line) e um relacionamento com a entidade Method (id_method). • A entidade Method, por sua vez, possui o nome do método que falhou (name) e um relacionamento com Class (id_class). • Por fim, a entidade Class possui o nome da classe (name) e o seu caminho (path) no que diz respeito ao pacote em que a classe se encontra.. 3.5. Avaliando o Algoritmo de Extração de Stack Traces. Com o intuito de avaliar o algoritmo de identificação de stack traces na extração de dados, foram utilizadas medidas de avaliação de sistemas de recuperação de informação6 . 6. Recuperação de Informação é o nome do processo onde um possível usuário de informação pode converter a sua necessidade de informação em uma lista real de citações de documentos armazenados que.

(37) 35. Dado um algoritmo de recuperação de informação, as medidas de avaliação devem quantificar a similaridade entre o conjunto de documentos recuperados pelo sistema e o conjunto de documentos considerados relevantes pelos especialistas. Isto fornece uma estimativa da qualidade do algoritmo de recuperação de informação avaliado [2]. Dentre as medidas de avaliação, as mais utilizadas são a precisão e a cobertura. Precisão é a proporção dos documentos recuperados que são relevantes para uma dada consulta em relação ao total de documentos recuperados. Cobertura é a razão entre o número de documentos recuperados que são relevantes para uma consulta e o total dos documentos na coleção que são relevantes para a consulta. A Figura 9 ilustra essas métricas.. Figura 9: Cálculo da Precisão e Cobertura.. 3.5.1. Cálculo da Precisão. Nesse estudo, foi feita uma análise utilizando essas métricas. Inicialmente foram escolhidas, aleatoriamente, 50 postagens, entre perguntas e respostas, como amostra. Essa amostra foi selecionada seguindo os seguintes passos: (i) identificação do número total de stack traces extraídas; (ii) sorteio de 50 números diferentes no intervalo entre 1 e o total obtido; (iii) identificação das postagens (perguntas ou respostas) vinculadas as stack traces extraídas. A partir desta amostra, foram utilizados os seguintes critérios que definem a relevância de cada item da amostra: Todas as stack traces presentes na postagem foram identificadas pelo algoritmo? Algo que não é stack trace foi identificado como tal? Para responder a estas perguntas, cada postagem da amostra foi analisada de forma contenham informações úteis a ele..

(38) 36. manual. Foi feita uma comparação entre os dados das stack traces armazenadas na base de stack traces e o conteúdo real da postagem. Para isso, a postagem foi visualizada pelo próprio site do stackoverflow.com através do identificador da pergunta e resposta registrado na Tabela Stacktrace, como já relatado no final da Seção 3.4. Por exemplo, para acessar a postagem com o identificador 5859377 basta acessar o site através da seguinte URL https://stackoverflow.com/questions/5859377 7 . • Medição da Precisão: O resultado da análise das 50 postagens escolhidas aleatoriamente é ilustrada na Tabela 13 do Apêndice A deste trabalho. Das 50 postagens, 45 foram avaliadas como relevantes, seguindo o critério de que todas as stack traces existentes nas postagens foram identificadas pelo algoritmo e nenhuma das stacks eram falsos positivos. Dessa forma, a precisão obtida foi de 0,9 (45/50). Na análise manual dessas postagens, foi observado algumas limitações da expressão regular. Podemos destacar dois cenários para os quais houveram divergências entre a stack trace extraída na mineração em relação a stack trace real presente na postagem. – A Figura 10 mostra um exemplo em que dois blocos de stack traces são identificados pelo algoritmo como sendo uma única stack.. Figura 10: Exemplo de dois blocos de stack traces que foram identificados pelo algoritmo de extração como sendo apenas uma única stack. – Por último, a Figura 11 mostra um exemplo de stack trace que foi identificada erroneamente, por conter texto de log do sistema que é semelhante ao nome de uma exceção. Neste exemplo, cada frame foi reconhecido pelo algoritmo como sendo uma stack trace diferente. 7. Este recurso de busca de postagens pelo https://api.stackexchange.com/docs/questions-by-ids. seu. identificador. está. documentado. em:.

(39) 37. Figura 11: Exemplo de stack trace que não foi corretamente identificada pelo algoritmo de extração por conter texto de log do sistema. • Medição da Cobertura: Por outro lado, a métrica de cobertura não se aplica a amostra utilizada, uma vez que a amostra já tem como pré-requisito a existência de stack traces, logo todos os elementos da amostra conterá pelo menos uma stack trace. Caberia a utilização da métrica, se a amostra fosse realizada a nível de postagens em que conseguíssemos medir o quanto o algoritmo conseguiu extrair do total de stack traces que existem nas postagens, podendo a postagem ter ou não stacks.. 3.6. Análise de Dados Extraídos. Após a execução do algoritmo de extração de stack traces, foi feita uma análise dos dados. Alguns dos quantitativos são listados na Tabela 2. A partir dela pode-se visualizar o total de postagens existentes no arquivo dump, a quantidade de postagens para as quais foi identificado pelo menos uma stack trace, a quantidade de stack traces identificadas e a porcentagem de stack traces que significa a proporção entre a quantidade de postagens com stack traces e a quantidade de postagens existentes. Foi observado que do total das 21.736.594 postagens (entre perguntas e respostas) encontradas no arquivo de Dump, foram identificadas 121.253 stack traces em 77.852 (0,36%) postagens. Total de. Postagens com. Stack traces. Porcentagem de. Postagens. stack traces. identificados. stack traces. 21.736.594. 77.852. 121.253. 0,36%. Tabela 2: Total de postagens e de stack traces identificados na extração.. Também identificamos o total de métodos que possuem pelo menos uma ocorrência em stack trace extraído do SOF (conforme a Tabela 3). O número equivale a 213.635 métodos, dentre os quais 49.485 deles possuem pelo menos três ocorrências em postagens.

(40) 38. do SOF. Há uma média de 7,67 stack traces identificadas por método. Total de. Métodos com mais. Média de. Máxima Quantidade. Métodos. de 3 Stacks. Stack Traces. Stack Traces. 213.635. 49.485. 7,67. 22.240. Tabela 3: Quantitativos dos métodos identificados em stack traces mineradas.. É de se notar a baixa porcentagem de postagens que possuem stack traces. Isso se deve pelo fato do Stackoverflow ter um escopo amplo, que não envolve apenas exposição de falhas de sistemas, mas também questões de interesse geral dentro do contexto da programação. A partir desses dados podemos concluir que, em relação a sua quantidade total, há poucas postagens no StackOverflow que possuem dados de stack traces em seu conteúdo. Uma vez que o conteúdo das stack traces poderá contribuir para o desenvolvedor, independente da quantidade de postagens que ele tenha disponível através da ferramenta.. 3.6.1. Tags Mais Frequentes. Também analisamos as tags mais frequentes nas postagens onde pelo menos uma stack trace foi identificada. A Tabela 4 lista as tags por ordem de quantidade de postagens com stack traces.Do total de 77.852 postagens com pelo menos uma stack trace identificada, as postagens com a tag Java tiveram maioria na quantidade de postagens com stacks identificadas, no total de 33.056 (42,46%) postagens. Em segundo a tag Android, com 7.260 (9,32%) postagens e em terceiro a tag Spring com 4.561(5,85%). Já em relação a porcentagem de stack traces identificados, a tag NullPointerException lidera, das 6.880 postagens, em 1.762 (25,61%) delas foi identificado a existência de stack traces.Em segundo está a tag Exception que das 19.435 postagens contidas no arquivo de dump 3.208 (16,51%) delas possuem stack traces..

(41) 39 Total de. Postagens com. Stack traces. Porcentagem de. Postagens. stack traces. identificados. stack traces. Java. 708.473. 33.056. 42.459. 4,67%. Android. 564.955. 7.260. 11.102. 1,29%. Spring. 50.733. 4.561. 6.995. 8,99%. Hibernate. 37.988. 3.898. 7.448. 10,26%. C#. 694.653. 3.549. 4.139. 0,51%. Eclipse. 73.143. 3.208. 5.757. 4,39%. Exception. 19.435. 3.208. 3.931. 16,51%. NullPointerException. 6.880. 1.762. 5.436. 25,61%. Tomcat. 19.981. 1.972. 5.032. 9,87%. Tag. Tabela 4: Quantidade de postagens e de stack traces identificados para cada tag.. Considerando a porcentagem de postagens que incluem pelo menos uma stack traces, podemos observar que há uma alta porcentagem de postagens com as tags Hibernate e Spring. Isso sugere que o tema exceção uncaught (as quais são manifestadas nas stack traces) é um tópico frequente entre os desenvolvedores que utilizam Hibernate, Spring e Android. Além disso, outras tags, embora possuam menor número de postagens, elas tiveram maior quantidade de stack traces identificadas. Isso pode ser explicado pelo significado das tags, em especifico "NullPointerException" e "Exception". Elas sugerem que o autor da postagem se interessa pela resolução de um problema com exceções específicas e, por isso, possa ter detalhado melhor o erro com a inserção de maiores dados da stack traces no conteúdo da postagem. Embora possamos tirar algumas conclusões a partir desses dados, não podemos garantir que as tags expressam de maneira real o contexto do conteúdo da postagem. No StackOverflow fica a cargo do autor da postagem escolher e vincular a tag que compreender ser cabível à postagem. E em outros casos, poderiam existir postagens para as quais não foi vinculada nenhuma tag.. 3.6.2. Heurísticas Adotadas para Utilização da Base de Stacktraces Construída. Para utilização da base de stacktraces em análises e, posteriormente, como fonte de dados para a ferramenta proposta, elaboramos algumas heurísticas que permitiram filtrar dados desnecessários, deixando a base de stacktraces mais consistente, por exemplo, re-.

(42) 40. movendo interfaces excepcionais com poucas ocorrências e as que não sejam interessantes para conhecimento de aplicações clientes. • Métodos não públicos foram desconsiderados. Métodos protegidos e, principalmente, privados podem não ser acessados a partir de aplicações cliente e o desenvolvedor final não seria surpreendido por exceções que sejam lançadas por eles. • Foram considerados os métodos de qualquer nível da stack traces, seja sinalizador ou não. Nosso objetivo é identificar a popularidade das exceções não documentadas, justificando o uso da ferramenta para descobri-las. • Exceções do pacote "java.lang" e com terminação "Error" foram desconsideradas nas análises e construção da ferramenta. Segundo o estudo de Coelho et al [5], essas exceções representam a maioria das exceções implicitamente lançadas em tempo de execução devido a erros de programação (por exemplo, ArrayIndexOutOfBoundsException, NullPointerException) ou a limitações de recursos (por exemplo, OutOfMemoryError ). Em um cenário de reutilização de código, por se tratarem de exceções não checadas, dificilmente serão lançadas de forma explicita em uma API. Alguns estudos, como Bloch [3], argumentam que esse tipo de exceção pode ser encapsulada em forma de uma "IllegalArgumentException", por isso apenas essa exceção dentre as que compõem o pacote "java.lang"foi mantida. • Outra heurística utilizada se baseia no padrão "regra de três"(do inglês: rule of three). De acordo com Martin et al [20], um padrão não é um padrão a menos que haja pelo menos três fatos independentes e observáveis que ilustrem o padrão que está sendo usado. Em algumas análises e na construção da ferramenta proposta nesse estudo, consideramos os métodos cujas exceções possuem pelo menos três stack traces ocorridas em postagens do SOF. Essa heurística foi usada como uma forma de reduzir o efeito de métodos e exceções com poucas ocorrências no SOF, e que, por isso, podem ser caracterizadas por ocorrências especificas a uma determinada aplicação, tendo grandes chances de não se tratar de uma API.. 3.6.3. Inspeção de Exceções das APIs Spring, Hibernate e Android. • Motivação: Um estudo anterior de Kechagia e Spinellis [15] revelou que muitas exceções não capturadas sinalizadas em aplicações Android são exceções Runtime.