Supporting Source Code Search with Context-Aware and Semantics-Driven Code Search

Editor's Notes

• #2: Hello everyone! Good afternoon! Thanks for attending this meeting. My name is Masud Rahman. I am a PhD Candidate from Software Research Lab. I work with Dr. Chanchal K. Roy. Today, I will be talking about automated query reformulations for code search.
• #3: Today, my talk will be divided into four sections. In the first section, I will discuss the research problem I am trying to solve in my PhD. In the second section, I will discuss about my PhD Thesis proposals to solve that research problem. In the third section, I will summarize my PhD contributions. Finally, we will have a Q&A session and interesting discussions.
• #4: Part 1: Research Problem
• #12: Now, I am not going to discuss those studies in details. But here is the glimpse. Developers generally look for relevant code on the web using natural language query. Please note that we are not talking about simply web search, rather talking about source code repository such as GitHub. Now, GitHub provides this result. Now, you see it tries to match the query keywords with comment and identifiers. But what we are dealing with source code right? So, we need source code friendly query for a better result. So, we identify relevant API classes against this natural language query through extensive data mining and data analytics. And once again, Stack Overflow is our friend in this grand challenge.
• #14: Now, we are done with Background concepts, Part 1. Now, we are going into Part 2 -- PhD Thesis
• #15: So what we did? We did a systematic literature survey using 56 primary studies on query reformulation for code search. During this study, we found 3 major issues in the literature.
• #18: We did an empirical study with 5K+ bug reports in our ICSE poster. And we discovered that bug reports could be very different in terms of quality. There could be different types of bug reports. It could be noisy with stack traces which is 16% It could be really poor that does not contain any structured entities, which is 30% Or it could be rich bug reports that include source code, test case and other stuffs, which is 54%
• #20: Now, each trace will contain three piece of information – a package name, a class name and a method name. We know that, in a single line, the method and class are statically connected for sure. However, classes and methods are also hierarchically dependent across trace lines due to caller-callee relationships. We capture such static and hierarchical relationships from consecutive trace lines, and develop a trace graph like this.
• #21: So, we have created two graphs, right? Now, we have two graphs developed from the bug report based on two different dimensions --Word co-occurrence and syntactic dependence. Once we have graphs, we apply this famous algorithm called PageRank algorithm. This is the backbone of Google search. Now, the algorithmic details are a bit complex, but I will try to provide an overview here. Why do you think, this guy is laughing? Because, it is getting the maximum votes. Similarly, in the graph, the node that is connected to most of the nodes is the winner. That is, a term’s importance will be determined by its connectivity with other nodes. More importantly, since this is a recursive algorithm, the importance depends on the weights of the connected node as well. Once the computation is done, we get a reformulation candidate from each graph. What is the reformulation candidate? – a ranked list of keywords like this. So, we collect two candidates from two graph, apply machine learning and suggest the best one as our suggested query from the bug report.
• #22: So, from a noisy report, we extract The report title The encountered exception The most important keywords from the stack traces. Then we do the search with this newly constructed query. For example, the baseline noisy query returns the result at 53rd position. Whereas our query returns the correct result at the topmost position.
• #24: Now once such items are extracted, we split them. Now as we see, these single terms share some kind of semantics to convey a broader semantic. That is, they complement each other in this context. Now, we capture such semantic dependencies in the source code, and develop a term graph like this.
• #25: In the case of poor bug report, we also apply a similar PageRank approach. But we collect the keywords from the source code using pseudo-relevance feedback. The details can be found in the paper. So, the bug report texts are merged with the keywords from relevant source code. While the bug report texts return the result at 30th position. After feeding poor report with appropriate keywords, the correct result is returned at the top most position.
• #27: Now, for the experiments, we chose 8 subject systems from Apache and Eclipse. We collect about 3000 bug reports, and try to map them with the version control history at GitHub. Through such mapping we extract the ground truth for the bug reports. This is a standard process followed by the existing literature.
• #33: Now, I am not going to discuss those studies in details. But here is the glimpse. Developers generally look for relevant code on the web using natural language query. Please note that we are not talking about simply web search, rather talking about source code repository such as GitHub. Now, GitHub provides this result. Now, you see it tries to match the query keywords with comment and identifiers. But what we are dealing with source code right? So, we need source code friendly query for a better result. So, we identify relevant API classes against this natural language query through extensive data mining and data analytics. And once again, Stack Overflow is our friend in this grand challenge.
• #34: Now, we are done with Background concepts, Part 1. Now, we are going into Part 2 -- PhD Thesis
• #35: Thanks for your time and attention. Now, I am ready to take your questions.