Paper Review Mining Framework Usage Graphs from App Corpora
Scale the mining of API usage graphs from software.
Use frequent itemset mining (NOTE: recommendation algorithm for grouping frequently-used-together items together) to restrict the search for groums to smaller subsets of methods in the given corpus. Then, we pose the subgraph isomorphism as a SAT problem and apply efficient pre-processing algorithms to rule out fruitless comparisons ahead of time. Finally, we identify containment relationships between clusters of groums to characterize popular usage patterns in the corpus (as well as classify less popular patterns as possible anomalies).
scales on a corpus of over five hundred open source Android applications
graph-based object usage models (groums). Groums are a promising approach to represent usage patterns for object-oriented libraries because they simultaneously describe control flow and data dependencies
What you can learn from this to make your research better?
Their approach is a pretty standard way to clustering things together — probably better than NLP based approach (TF-IDF).
Details and Problems From the presenters’ point of view, what questions might audience ask?
How to validate the correctness of usage graphs?
We did our best to select the reference patterns in an unbiased way. We recognize that our understanding of the API usage and some of the online sources may in fact be erroneous. Two of the paper’s authors collected and validated the reference patterns, consulting additional documentation (e.g. StackOverflow posts, the Android source code) and, in the most uncertain cases, an Android developer. The evaluation of the patterns was manual and hence, prone to the same threats to validity. In this case, three of the paper’s authors validated the results. Finally, the classification of the patterns is not formal and hence it is open to interpretations.
Our future work will focus on overcoming some limitations of the approach, like using interprocedural analysis, and on code completion and automatic repair.
What are the size of each app? How does that impact the performance of the tool?
Since BIGGROUM works on byte-code, we tried to compile the apps (with the gradlew command), keeping only the ones that compile, for a total of 542 apps. Why not simply use APK?
We obtained the input required by the GrouMiner tool by slicing the app code in the corpus to produce a java code containing only the method of interest and the class members accessed by the method. What is the impact of this slicing operation?