A-SCORE: Automatic Software Component Recommendation
Using Coding Context
Ryuji Shimada
Yasuhiro Hayase
Makoto Ichii
Makoto Matsushita
Katsuro Inoue
Graduate School of Information Science and Technology, Osaka University{r-simada, y-hayase, m-itii, matusita, inoue}@ist.osaka-u.ac.jp
Abstract

Source code ofcomponents

Legends
Data

Reusing software components (e.g. classes or modules)
improves software quality and developer’s productivity. Unfortunately, developers may miss many reusing opportunities since current keyword based component search systems
cannot provide reusable components if the developers donot use them. This paper proposes a new automatic component recommendation system which supports various usage
scenarios and procedures for component reuse.

Controls

Contentof edit

DeterminesearchtimingInvokeEditsource code

Characteristics

Generate
query

Editor
Source code andcursor position
Developer
Recommend
components

Extractcharacteristics

Recommendation
view

Build index

Query

Searchcomponents

Index

Components

Figure 1. Overview of our approach

1

Automatic Component Recommendation
automatically extracts search conditions and requirements from the source code.

Reusing software components (e.g. modules or classes)
improves software productivity and quality [3]. There exists
a countless number of software components but developers
cannot easily beneﬁt from their reuse, since components are
sometimes poorly documented and not designed for reuse.
To ﬁnd reusable components satisfying certain requirements, developers often use keyword-based search systems.
However, keyword-based search systems recommend components only upon an explicit developer interrogation; consequently, developers may miss a signiﬁcant number of opportunities for reusing some software components.
To deal with the problem, Ye et al. proposed an automatic component recommendation system: CodeBroker[4]. Automatic component recommendation systems
collect search conditions and requirements while developers edit the source code, and recommend possible reusable
components without being explicitly instructed. These systems have two advantages over ordinary keyword searchsystems:

Although there are many way to reuse software components, CodeBroker supports only the replacement of a new
method with an already existing one; other ways to reuse acomponent are not supported by the tool.
This paper proposes a new automatic component recommendation system. Our system extends CodeBroker’s approach at component reuse and supports not only method replacement, but also modiﬁed component imports and codefragment copy-and-paste operations. The system uses comments and identiﬁers to extract developer’s requirements
and search conditions.

2In our approach components are represented by Javaclasses. Recommended components are similar to those thedeveloper is editing in the meaning of Latent Semantic Indexing (LSI)[1]. The co-occurrence matrix between documents and words required for LSI searching is computed
using components source code as documents and their characteristics as words.
Our approach is divided in two phases: index building
and recommendation (see Figure 1). Each phase is de-

1. the system can recommend components even if the developer thinks there are no reusable components because it automatically searches possible reusable components;
2. the system can search components even if the developer cannot provide good search keywords because itICSE’09, May 16-24, 2009, Vancouver, Canada
978-1-4244-3494-7/09/$25.00 © 2009 IEEEApproach

439

Companion Volumescribed below.
Source Code Editor

Indexing 1: Characteristic Extraction. Firstly, the component’s source code is parsed for extracting elements including characteristics. The elements are document/normal
comments, class/method/ﬁeld/local-variable declarations,and method invocations. Then, each element is divided into
discrete words.

Import to current projectIndexing 2: Index Building. Firstly, the characteristic-bycomponent co-occurrence matrix is built. The (i, j) elementof the matrix represents the number of occurrence for the ith characteristic in the j-th component. A row vector of theco-occurrence matrix is called component vector. Then, thedimension relative to component’s characteristics is reduced
and the matrix is transformed into an LSI-index.

Recommendation
View
Double-click
to showsource code

Recommendation 1: Search Invocation. Editing operations are monitored and searches initiated at appropriate
time. Speciﬁcally, searches are triggered when a statement
delimiter (semicolon, brace or end-of-comment mark “*/”)is typed, or when the cursor is moved out of a statement orcomment after a modiﬁcation.

Figure 2. A Screen Snapshot of A-SCORE
if A-SCORE’s automatic recommendations are enabled,reusable component candidates are automatically presented
in the recommendation view. If the developer double-clicks
a candidate in the view, the source code of the selected component is displayed in a new editor window. A right-click
on a candidate allows the developer to display the details of
the selected candidate using SPARS-J[2] or, if the developer
decides to reuse the component, to automatically download
and import the component into the current project.

Recommendation 2: Query Generation. A query is represented by a set of tuples < characteristic, weight >.
Characteristics are extracted from the edited source code in
the way illustrated at the Indexing 1 clause. The weight isa positive real value attenuated by the characteristic’s distance from the cursor, and represents the relevance of thecharacteristic for the search.
Recommendation 3: Components Search. The index isused to search components matching the query previously
built, and the results are presented to the developer. Firstly,
the query is transformed into a pseudo-component vector,
a sequence of the query’s weights in the same order of thecomponent vector; the weight value of characteristics notpresent in the query is zero. Then, the several components
are presented to the developer in descendant order of theircosine similarity value to the pseudo-component vector.

3Show detail
informationin SPARS-J

Acknowledgment
This work was supported by KAKENHI (18650006) andsupported in part by “Global COE (Centers of Excellence)
Program” of the Ministry of Education, Culture, Sports,
Science and Technology, Japan.

References[1] S. Deerwester, S. Dumais, G. Furnas, T. Landauer, andR. Harshman.
Indexing by latent semantic analysis.
J.Am.Soc.Inf.Sci, 41(6):391–407, 1990.
[2] K. Inoue, R. Yokomori, T. Yamamoto, M. Matsushita, andS. Kusumoto. Ranking Signiﬁcance of Software Components
Based on Use Relations. IEEE Trans. on Softw. Eng., pages
213–225, 2005.
[3] C. Krueger. Software reuse. ACM Computing Surveys(CSUR), 24(2):131–183, 1992.
[4] Y. Ye and G. Fischer. Reuse-Conducive Development Environments. Automated Softw. Eng., 12(2):199–235, 2005.

Tool Implementation

This section describes A-SCORE (Automatic Software
Component Recommendation Environment), the tool implementing our approach.
A-SCORE is structured as a client-server system: theserver is implemented as a web service and the client is implemented as an Eclipse plug-in. The elements in Figure 1
from Source code of components to Search Components areimplemented in the server, and the rest in the client.
Figure 2 shows a snapshot of A-SCORE. The bottomright view in the main window is the A-SCORE user interface. While a developer is editing the source code,440