Towards a Visualized Code Recommendation for APIs Enriched with Specification Mining Mohammad Ghafari
Abbas Heydarnoori
DeepSE Group @ DEIB Politecnico di Milano, Italy
Department of Computer Engineering Sharif University of Technology, Iran
[email protected]
[email protected]
ABSTRACT This paper positions an idea for an interactive code recommendation system. In this work, candidate recommendations are abstracted as a graph-based visualization of the API usages that are decorated with the API specifications and the usage rules mined from the unit test cases of the given API and its usage examples. The user can then progressively explore this graph to obtain her desired code without delving into the implementation details.
Categories and Subject Descriptors D.2.6 [Software Engineering]: Programming Environments
General Terms Languages, Documentation
Keywords Code recommendation, unit test, specification, visualization
1.
INTRODUCTION
Developers spend a significant amount of their time on understanding and learning the correct usage of Application Programming Interfaces (APIs) of libraries and application frameworks that they want to employ in their software systems. Robillard et al. [3] show that, in practice, insufficient or inadequate examples represent the greatest obstacle to effectively learn an API. In response to the increasing need of meaningful code examples, research has been focusing on techniques to automatic extraction or generation of them. Approaches that provide relevant coding examples for developers are commonly referred to as code recommendation systems. However, we believe that merely relying on code examples of an API is not enough but a developer first needs to learn the basics of that API in order to be able to effectively use a recommendation. This aspect becomes even
more relevant during the software maintenance where maintainers have to deal with multiple and different APIs that they may have not exercised neither recently nor frequently. In practice, there are two main possibilities when a developer receives a code recommendation: either (i) she assumes that she has got her desired code snippets and continues to write other parts of her code, or (ii) she needs to manipulate the recommended code to tailor it for her needs. While in the former case, the developer may blindly use the suggested code, in the latter case which is more usual, depending on the API’s complexity, she may still need to refer to API’s documentation or other resources to realize how to appropriately use the recommended code. Thus, a basic knowledge of the API is a prerequisite for a developer to mitigate the risk of misusing an API, particularly when the developer has not enough familiarity with that API. Motivated by this requirement, this paper proposes an interactive code recommendation system which aims at enriching the knowledge of developers about an API while using a code recommendation system. The main idea of this work is to provide a graph-based visualization of recommended API usages that are decorated with API specifications and the usage rules mined from the unit test cases of the given API and its usage examples. The rest of this paper is organized as follows. Section 2 presents a motivating example to clarify the problem. The idea of the paper is described in Section 3 followed by related work in Section 4. Finally, Section 5 concludes the paper.
2.
MOTIVATING EXAMPLE
Imagine a developer who is looking for a table-like data structure in Java. In a very first step of searching the web, she might be offered to use the Google Collections Library, an extension to the Java collections framework that contains the ArrayTable data structure as it is shown in Listing 1. ArrayTable table = create("foo", 1, ’a’, "bar", 1, ’b’);
Listing 1: ArrayTable in Google Collections Library. A developer who is not familiar with this library may assume that this type of collection follows the same behavioral conventions that are common in native Java collections like ArrayList. Nevertheless, ArrayList.size() provides the number of objects which are actually stored in the array whereas ArrayTable.size() provides the capacity that is always 6 in the given example. In fact, an ArrayTable is of fixed length and cannot be resized once created.
Permission to make digital or hard copies of all or part of this work for personal or classroom usetois make granteddigital withoutorfeehard provided thatofcopies not made or work distributed Permission copies all orarepart of this for for profit or commercial advantage and that copies bear this notice and the full citation personal or classroom use is granted without fee provided that copies are on the first page. Copyrights for components of this work owned by others than ACM not made or distributed forwith profit or iscommercial and that copies must be honored. Abstracting credit permitted. Toadvantage copy otherwise, or republish, to postthis on notice servers and or tothe redistribute to lists, specific permission and/ortoa bear full citation onrequires the firstprior page. To copy otherwise, fee. Requesttopermissions from
[email protected]. republish, post on servers or to redistribute to lists, requires prior specific
permissionJune and/or a fee.Hyderabad, India RSSE’14, 3, 2014, RSSE ’14, 2014 June 3, 2014, Hyderabad, India Copyright ACM 978-1-4503-2845-6/14/06...$15.00 http://dx.doi.org/10.1145/2593822.2593825 Copyright 14 ACM 978-1-4503-2845-6/14/06 ...$15.00.
26
This simple example shows how a developer may get into trouble to reuse a code if she is not aware of an API’s specifications. In other words, merely relying on an API’s examples is not always sufficient due to the peculiarity of APIs which developers should know in advance to correctly use the recommended code.
3.
zero. However, if we look at Listing 3 which is part of a test case related to the ArrayTable, it indicates that the erase() operation clears the associated value in the table (line 3), but has no effect on the size of the table (line 4). Thus, as ArrayTable.size() provides the capacity that is always 6 in the given example, the code in Listing 2 gets into an infinite loop (line 2) and remains buggy till it is tested. To address this issue, we enrich our graph representation of candidate recommendations with the API specification corresponding to each node. Therefore, the user feels more confident about her code since she would be aware of each method’s preconditions, postconditions, and invariants. We obtain this knowledge by applying a client-side specification mining approach [4] on the unit tests of a given API and its usage examples. The rationale behind using unit tests is that we believe tests represent a handy source of information from which it is possible to synthesize meaningful and useful knowledge that can be shown as relevant information to developers.
PROPOSED IDEA
Assuming an API usage pattern as a sequence of method calls, it can be visualized as a directed graph in which each node indicates an API method call and each edge demonstrates an execution sequence of two operations. An example of this representation is illustrated in Fig. 1. This graph shows typical method calls on an ArrayTable. Looking at such a high level model rather than exploring the code directly, alleviates to rapidly get an abstract picture of an API. To explore the code at different levels of granularity, it is even possible that nodes of the graph indicate other kinds of computational units as well like line of code, packages, and so on. We leverage this approach to hide the implementation details of candidate code recommendations.
4. RELATED WORK To the best of our knowledge, none of the existing approaches on code recommendation systems take the advantage of leveraging API specifications during code recommendation. For example, MAPO [5] mines and indexes API usage patterns as sequential rules and recommends the associated code examples. In a recent study, Buse and Weimer [1] present an algorithm to automatically synthesize humanreadable API usage examples from a given software corpus. The generated examples are free from superfluous context and contain only the program statements needed to show the target behavior. While none of these approaches present the results graphically, ExPort [2] presents API usage examples as an interactive call-graph visualization. This code search engine, however, is not integrated into an integrated development environment (IDE) and requires a developer to step out her IDE, formulate a query using simple text, inspect the results and manually port the solution back to the IDE.
erase
create
put
eraseAll
Figure 1: Common usage patterns of an ArrayTable.
1
2 3 4 5
ArrayTable table = create("foo", 1, ’a’, "bar", 1, ’b’); While (table.size() > 0) { table.erase(..); // do something }
5. CONCLUSION Developers might not be able to properly reuse a recommended code for an API, if they are not familiar enough with the API. This paper proposed an idea to mitigate this issue by visualizing an API usages during recommendation and decorating them with the API specifications and usage rules mined from unit tests of that API and its usage examples.
Listing 2: an infinite while loop in the code. 1
2 3 4
ArrayTable table = create("foo", 1, ’a’, "bar", 1, ’b’); table.erase("bar", 1); assertNull(table.get("bar", 1)); assertEquals(6, table.size());
6. REFERENCES [1] R. P. L. Buse and W. Weimer. Synthesizing API usage examples. ICSE ’12, pages 782–792, 2012. [2] E. Moritz, M. Linares-Vasquez, D. Poshyvanyk, M. Grechanik, C. McMillan, and M. Gethers. ExPort: detecting and visualizing API usages in large source code repositories. ASE ’13, pages 646–651, Nov. 2013. [3] M. Robillard. What makes APIs hard to learn? the answers of developers. IEEE Software, 2011. [4] M. Robillard, E. Bodden, D. Kawrykow, M. Mezini, and T. Ratchford. Automated API property inference techniques. IEEE Transactions on Software Engineering, 39(5):613–637, May 2013. [5] T. Xie and J. Pei. MAPO: mining API usages from open source repositories. MSR ’06, pages 54–57, 2006.
Listing 3: part of the testErase test method. First, the user is provided with a graph which is relevant to her current development context. As she selects a node and explores the graph along the edges (selects a sequence of method calls), helps the recommendation system to obtain a more complete knowledge of her development task and accordingly, providing her a sub-graph which is more specific to the usage examples of her interest. Finally, the implementation details of each node could be shown to her. To accomplish this goal, we apply a sequential pattern mining technique [4] to mine sequences of API calls that are often used together in the source of existing sample projects. Listing 2 shows an example in which the user is trying to repeat an operation while the table size is bigger than
27
