4 Trabalhos Relacionados
4.2 Estudos que Mineram Informações sobre APIs
O trabalho de Parnin et al. (PARNIN et al., 2012) fala sobre potencial da documentação
que pode ser gerada pela multidão (do inglês, Crowd Documentation). O trabalho fala mais especificamente documentação sobre uso de APIs, que são programas desenvolvidas por poucos e usados por muitos. O trabalho fala que a documentação de APIs é muitas vezes pobre e carente de exemplos. O trabalho investigou como o Stack Overflow (SOF)
25http://shoreline.inf.usi.ch 26http://pharo.org
viabiliza a crowd documentation. O estudo identificou que os usuários do SOF são capazes de gerar informações ricas com exemplos em diferentes contextos. Porém o trabalho aponta também limitações da crowd documentation(e.g., diferentes versões de APIs), mas que apesar destas é uma fonte de informação promissora.
Souza, Campos e Maia (SOUZA; CAMPOS; MAIA, 2014a) propõem a construção de
cookbooks para APIs (i.e documentação orientada a receitas) a partir da mineração de informações do SOF. A abordagem utilizada no trabalho utiliza LDA (BLEI; NG; JORDAN,
2003) para identificar um potencial capítulo para o cookbook. A abordagem foi avaliada em três APIs (i.e., SWT, STL e LINQ) amplamente utilizadas. Foi avaliada a qualidade e a organização do cookbook gerado. Os resultados foram promissores 63–71% dos capítulos do cookbook eram bem definidos e tinham receitas relevantes (72–88%). Os resultados dos cookbooks gerados foram disponibilizados em um website. Posteriormente o trabalho foi estendido com experimentos considerando problemas de programação específicos das três APIs.
Acreditamos que nosso trabalho é complementar a este, pois as exceções que fluem por um dado método e não são documentadas pelos desenvolvedores fazem parte do comportamento do método e deveriam portanto fazer parte de sua documentação. Assim como este trabalho disponibilizamos as informações relacionadas às interfaces excepcionais descobertas das APIs analisadas neste estudo em um website.
Campos et al. (CAMPOS et al., 2014) apresentaram uma ferramenta chamada Nuggets
Miner, implementada na forma de plugin para a IDE Eclipse. Esse plugin possibilita que o usuário realize suas pesquisas sem ter que sair do ambiente de desenvolvimento. Caso o código trabalhado no momento estivesse hospedado no GitHub, também seriam consideradas nas pesquisas as issues, que já tenham sido resolvidas, isto é, que já possuíam o status de fechada por outros desenvolvedores.
4.3 Ferramentas que Utilizam Informações de
Stack
Traces
Amintabar, Heydarnoori e Ghafa (AMINTABAR; HEYDARNOORI; GHAFARI, 2015) pro-
puseram uma ferramenta integrada à IDE Eclipse, chamada de ExceptionTracer, para recomendar as possíveis soluções de exceções, que ocorrerem em tempo de execução. Para isso, utilizaram o conhecimento obtido através issues e commits do SourceForge27,
e postagens do StackOverflow. Essa ferramenta, porém, não analisava as stack traces das postagens, e utilizava uma abordagem passiva, exigindo que uma falha ocorresse, para que as recomendações pudessem ser processadas.
Rahman, Yeasmin e Roy (RAHMAN; YEASMIN; ROY, 2014) sugeriram uma solução de
pesquisa a partir da IDE Eclipse, que explorava os algoritmos de busca e classificação de quatro mecanismos: Google28, Bing29, Yahoo30 e StackOverflow. Para isso, era necessário
que o desenvolvedor selecionasse uma exceção, que tivesse ocorrido em seu programa, e a ferramenta coletaria as informações de contexto da falha para, em seguida, gerar uma requisição de busca.
Ponzanelli (PONZANELLI; BACCHELLI; LANZA, 2013;PONZANELLI et al., 2014) propôs
as ferramentas SeaHawk31 e Prompter32, respectivamente. Ambas buscam prover meca-
nismos para auxiliar os desenvolvedores a localizarem e analisarem postagens no StackO- verflow que estejam relacionadas com suas atividades. Para isso, a SeaHawk permitia que pesquisas no StackOverflow fossem feitas sem sair da IDE, além de exibir as postagens localizadas. Essa ferramenta permitia também que trechos das postagens fossem movidos para o editor da IDE. Já a Prompter, extraia informações do contexto do código fonte, que estava sendo editado, e realizava buscas em outras fontes de pesquisa, como Google, Bing e Blekko33. Ao final, classificava os resultados obtidos, seguindo vários critérios de
relevância, para recomendar os resultados mais relevantes. Nenhuma das duas ferramentas citou o uso de análise das stack traces existentes nas postagens, ou a identificação das interfaces excepcionais dos métodos.
No nosso trabalho não chegamos a implementar uma ferramenta integrada a IDE para apoiar o desenvolvimento do código de tratamento de exceções todavia, este é um desdobramento claro do presente trabalho uma vez que foi montada uma base de stack traces mineradas e de interfaces excepcionais que permitirá que ferramentas integradas a IDE possam acessar esta informação e apresentá-las ao desenvolvedor.
28https://www.google.com 29https://www.bing.com 30https://www.yahoo.com 31http://seahawk.inf.usi.ch 32http://prompter.inf.usi.ch 33https://blekko.com
4.4 Considerações Finais
Observamos nos trabalhos citados, certa semelhança no que diz respeito ao uso das informações contidas em serviços de perguntas e resposta, mais comumente o StackO- verflow com o objetivo de prover uma melhoria na obtenção e análise de postagens. A maioria desses trabalhos buscavam contornar o problema dos desenvolvedores precisarem ficar alternando, constantemente, entre IDE e o site do mecanismo de pesquisa utilizado, permitindo que realizassem suas pesquisas e tivessem os resultados exibidos na própria IDE. Eram raros os trabalhos que abordavam a utilização de outras fontes de dados, e dentre os que o faziam, geralmente, eram para linguagens diferentes de Java ou para contextos específicos.
Apenas os trabalhos de Campos et al (SOUZA; CAMPOS; MAIA, 2014b; CAMPOS et
al., 2014) propuseram recuperar informações do GitHub para apresentá-las aos desenvol-
vedores, porém ainda demandando destes a inserção de termos a serem pesquisados, e restringindo às issues já fechadas do próprio projeto. Nessa proposta, era necessário um grande esforço por parte dos desenvolvedores para análise das informações obtidas, pois uma vez exibida a lista, era preciso clicar sobre cada item, e navegar pelas postagens apresentadas em um web browser na IDE. Esses trabalhos também não faziam uso exclu- sivamente das stack traces postadas, eram consultados também os termos presentes nos título e respostas das postagens.
Portanto, o que diferencia o presente trabalho, das demais pesquisas realizadas, é a contribuição com um estudo de identificação de interfaces excepcionais de APIs Java, a partir da mineração do conhecimento da multidão embutido nas stack traces postadas em issues trackers da mais popular plataforma de hospedagem de projetos – GitHub.
5
Conclusões
Este trabalho relatou um estudo exploratório que extraiu as stack traces inseridas em issues do GitHub para descobrir as interfaces excepcionais não documentadas de APIs. No geral, foram mineradas as issues de 2.970 projetos Java hospedados no GitHub, dos quais foram extraídas 66.118 stack traces.
Neste estudo, foram extraídas as interfaces excepcionais de dois grande conjuntos de bibliotecas hospedadas no repositório central do Maven. Juntos, os dois conjuntos forneceram mais de 700 artefatos. A partir da análise das interfaces excepcionais das APIs, pudemos observar que há um déficit de documentação excepcional.
A partir da análise das stack traces reportadas em issues do GitHub, descobrimos que em média 66,7% de todas as bibliotecas analisadas eram citadas em stack traces. Encontramos também exceções não checadas (RuntimeException) não documentadas em métodos não privados das bibliotecas. Essas exceções são bastante relevantes, já que ao menos uma vez se manifestaram, provavelmente não foram de imediatamente solucionadas, o que resultou em postagens em issue trackers. Isso também nos mostra que é possível identificar ao menos uma parte significativa das interfaces excepcionais dos métodos nas stack traces analisadas.
Identificamos que em média, mais de 84% das bibliotecas analisadas, possuíam mais issues contendo stack traces relacionadas com exceções não documentadas, do que docu- mentadas. Observamos também que para as dez libs de cada conjunto que identificamos mais issues, em média um único método está relacionado com mais de 46% delas. Isso pode nos indicar que dentre todos os métodos que compõem uma biblioteca, apenas um pequeno conjunto de métodos de cada biblioteca está envolvido nas stack traces reporta- das.
Ao longo deste estudo descobrimos interfaces excepcionais para um conjunto de APIs hospedadas no Maven Central Repository. Disponibilizamos no site https://github. com/lucasmgaldino/ExceptionalInterfaceFromGitHubStudy, as exceções documenta-
das e não documentadas (foco do trabalho) descobertas para cada um dos métodos das APIs analisadas, juntamente com o número de projetos afetados. O objetivo de disponibi- lizar esta informação é tornar tanto os clientes quanto os desenvolvedores de APIs cientes destas exceções que só seriam descobertas em tempo de execução.
Por fim, confrontamos as interfaces descobertas através da análise de stack traces com as obtidas com o auxílio da ferramenta de análise estática PLEA. Vimos que a intercessão entre os dois conjuntos resultantes é praticamente inexistente, o que nos sugere que as stack traces existentes em issue trackers do GitHub podem servir de fonte de informação sobre interfaces excepcionais de bibliotecas Java, complementando assim as ferramentas de análise estática.