Building Domain Specific Dictionaries of Verb-Object Relation from Source CodeYasuhiro Hayase
Faculty of Information Sciences and Arts
Toyo University
Kawagoe, Saitama, Japan
Email: hayase@toyo.jp

Yu Kashima
Yuki Manabe
Katsuro Inoue
Graduate School of Information Science and Technology
Osaka University
Suita, Osaka, Japan
Email: {y-kasima,y-manabe,inoue}@ist.osaka-u.ac.jp

Abstract—An identifier is an important key in mapping
program elements onto domain knowledge for the purposeof program comprehension. Therefore, if identifiers in a
program have inappropriate names, developers can waste
a lot of time trying to understand the program. This paper
proposes a method for extracting and gathering verb-object(V-O) relations, as good examples of naming, from sourcecode written in an object-oriented programming language.
For each of several application domains, dictionaries containing the V-O relations are built and evaluated by softwaredevelopers. The evaluation results confirm that the relationsin the dictionaries are adequate in many cases.

I. I NTRODUCTION
Program comprehension consumes at least half thetime allocated to the software maintenance process [1],[2]. Identifiers in the source code are very important for
program comprehension. Software developers generally
try to understand a program by guessing the roles of the
program elements from their identifiers [3], [4].
In general, an identifier consists of several words, andmultiple identifiers are used to represent the behavior of aprogram. As a result, various relations exist between thewords in identifiers. For example, the name of a method
has a verb-clause representing its behavior together with
optional object-clauses in most cases. The name of themethod relates to the name of the class and formal
parameters when declaring the method, or receiver object
and actual parameters when calling the method. These
related identifiers sometimes assume the role of the objectclause for the verb in the method name.
Accordingly, if identifiers in a program have inappropriate names, it is difficult for developers to guess therole of the program elements and map the elements onto
knowledge of the application domain. Lawrie et al. [5]revealed that identifiers that are acronyms or meaninglessserial numbers cause developers to waste much more timein program comprehension, compared to when identifiers
are spelled out fully without any abbreviations. Therefore,software developers should give identifiers names that
accurately represent the role of the program elements whencreating or changing source code.
Unfortunately, not all developers are able to give appropriate names to identifiers, since a broader knowledge anda great deal of experience are necessary to define accuratenames. Developers need to learn the rules of various words
and their combinations (e.g., naming rules) in different

domains, such as the programming language, development
organization or application domain. The only way to learn
these rules is through examples, since the rules are notdocumented in many cases.
For the purpose of naming identifiers, our researchgroup is working on building dictionaries containing good
examples of identifier names. The dictionary has a network
structure. In a previous work, we proposed a method forbuilding a dictionary of the super-sub (abstract-concrete)
relation of nouns used in identifiers [6]. We believe thatthe dictionary is useful for naming classes and variables.
This paper proposes a method for building a dictionary of verb-object (V-O) relations extracted from sourcecode. In particular, verbs are extracted from a methodname using existing natural language processing and thepattern matching system we developed, and then objects
are extracted from the method name, names of formal
parameters of the method, and the name of the class towhich the method belongs. This process is applied toa set of source files categorized by application domain.
Relations that appear frequently in a domain are includedin the dictionary for that domain.
The proposed method was applied to Java source files
belonging to four different domains, and the generated
dictionaries evaluated by developers. The results of theevaluation confirm that most of the entries in the dictionaries are domain specific relationships and general relationsin Java source code.
The rest of the paper is structured as follows. Section
II-B explains in detail the V-O relationship in objectoriented programs and naming rules of methods, while
Section III presents the algorithm used to build a dictionary of V-O relations from source code. Section IV
discusses the evaluation experiment and its results. Finally,
Section V discusses related works, while Section VI gives
our conclusions and future works.
II. V ERB -O BJECT R ELATIONS IN O BJECT-O RIENTED
P ROGRAMS
This section explains in detail the V-O relationship inmethods of object-oriented programs. First, the naming
rule for identifiers in object-oriented languages, especiallyJava, is given. Then the V-O relationship between words
in identifiers, which are related to method declarations, isdescribed.

A. Naming rule for identifiers
In general, it is recommended that an identifier has a
specific and obvious name that expresses its role. Since
the role of identifiers is sometimes complicated in objectoriented programs, an identifier in an OO program isoften expressed as a compound name, consisting of several
words.
Unfortunately, white spaces are prohibited in identifiersin many programming languages, and therefore, alternative
ways are employed to express compound names, i.e.,
camel case and snake case. Camel case refers to a concatenated string of words, whose first letters are capitalized(e.g., CamelCase). Snake case is a concatenated string ofwords with underscores between words (e.g., snake case).
In Java source code, camel case is recommended and ismost popular [7].
Commonly, the name of a method in an object-oriented
program includes a verb. In most cases, the head ofthe method name is a verb or verb clause, followed
by a noun or adjectives. In other cases, the head ofthe method name is a noun or adjective, or a noun or
adjective clause, followed by a verb in the past tense.
For example, java.awt.event.ActionLister
in
the
Java
API
[8]
has
a
methodactionPerformed(ActionEvent).
In a few cases, the method name contains no verbs.
For example, the names of the toString() method ofjava.lang.Object and newInstance() methodof java.lang.Class do not contain any verbs. From
one point of view, these methods omit the obvious verbs,
such as convert or create. The alternative view is that toand new act as verbs in the methods. This paper adopts
the latter view.
B. Verb and Object Words in a method
Object-oriented programs contain many statements describing operations on targets. An operation and a target
correspond to a verb and an object, respectively. Receiveror parameter objects are used as the targets of the operation. Fry et al.[9] proposed a method to extract verbs anddirect objects from method names and parameters or classnames, respectively.
In source code, there are many pairs of verbs
and objects that seldom appear in natural language
texts. For example, java.net.Socket has a methodbind(SocketAddress). The method name actuallymeans “bind SocketAddress to Socket”. However, in natural language text, except for programming documents,
socket almost never acts as the object of the verb “bind”.
Moreover, the verb-object relations that appear in sourcecode are sometimes specific to a certain program domain,
since programs in different domains use different words,
or the same words with a different meaning. For instance,
in a database domain, noun cursor is used as a pointer toselected data for the purpose of accessing the data one-byone. On the other hand, in the GUI application domain,
cursor means the editing point of a text area. Only in a

database domain does fetch from cursor mean to acquire
one set of data from the database.
III. A PPROACH TO O BTAINING V-O R ELATIONS FROMS OURCE C ODEThis section describes a method to build a dictionaryof V-O relations by extracting the relations from objectoriented programs. The input to the method is source
files for a certain domain written in an object-oriented
language, while the output is a dictionary composed oftuples consisting of a verb (V), direct-object (DO), andindirect-object (IO) specific to the domain. The IO field
may be empty. An outline of the approach is shown in
Figure 1.
The approach consists of the following three steps.
• Step 1: Obtaining the identifiers related to eachmethodRetrieve all method declarations in the input source,
and then for each declaration, obtain identifiers that
relate to a declaration.
• Step 2: Extracting V-O relations
Analyze the output of step 1 to obtain the words foreach identifier and the word class for each word. This
information is expressed as a tuple consisting of V,
DO, and IO.
• Step 3: Filtering V-O relations
From the output of step 2, select the tuples that appear
in more than a certain number of software products.
The following section describes each step.
A. Step 1: Obtaining the identifiers related to each method
This step extracts all the method declarations and related
identifiers from the input source files. In particular, source
files are parsed to extract all method declarations. Then,for each method declaration, the return type, name of
the method, names and types of formal parameters, andthe name of the class to which the method belongs, areextracted.
B. Step 2: Extracting V-O relations
This step analyzes the output of step 1 to obtain thewords comprising the identifiers and a part of speechfor each word. This information is expressed as a tuple
consisting of V, DO, and IO.
Extracting the V-O relations is done in the following
stages.
• Obtaining the method property
Acquire the words relating to the method, together
with their parts of speech, (the method property)
from the output of the previous step.
• Extract V-O relations by pattern matching
Acquire the tuples consisting of <V, DO, IO> byapplying a pattern matching technique to the method
property.
Details of the method property and how we obtain theinformation is described below. Thereafter, we explain thepatterns and pattern matching algorithm.

Source Products
in a same domain

Extracted V-O Relation

Method property
Vvoid add Product(Product) in Stockverb noun noun
noun

DO

IO

# of
products

Add

Product

Stock

3

Build

Data

Matrex

1

Set

Password

User

4

Describe

Alias

Xml

1

Pattern Match

Filtering
Extraction Pattern
V-O Dictionary

void verb1 noun2 (noun2) in noun3
V: 1
DO ： 2
IO ： 3Figure 1.

V

DO

IO

Add

Product

Stock

Set

Password

User

Overview of our approach

Method Property
void
VOID

create Ticket For Userverb noun prepos noun

User
noun

Servernoun

Extract the words according to a extraction spec
if a structure spec matches to a method property

Pattern Match
Extraction Pattern
Structure Spec
return type

method nameparametersclass name

V-DO-IO tuple
void

verb1 noun2 prepos3 noun4

wild card

wild card

Verb

Direct Object

Indirect Object

createTicketUser

Extraction Spec
Verb

Direct Object

Indirect Object

1

2

4

Figure 2.

Method property, extraction pattern and pattern matching1) Obtaining the method property: Method property isexpressed as a tuple of four sequences of words together
with their respective parts of speech. (Figure 2) The four
sequences respectively correspond to the return type of themethod, the name of the method, the parameters of themethod, and the name of the class to which the method
belongs. If the method has one or more parameters, twotuples are produced for the method property; one contains
the sequence of types of the parameters in the third
element, while the other contains the sequence of namesof the parameters. The procedure to acquire the method
property from the identifiers obtained in the previous stepis described below.
The first element of the method property is a sequencethat only contains the return type of the method. If themethod has a non-void return type, the name of the return
type is treated as a noun. Otherwise, the return type voidis treated as a special part of speech ”VOID”.

The fourth element is almost the same as the firstelement; it is a sequence containing only the class name,which is treated as a noun.
The third element is a sequence with length greater than0. The n-th formal parameter of the method corresponds
to the n-th element of the sequence. As described above,formal parameter names and their types are respectively
used for two method properties. Since the procedure tobuild the sequence is the same, parameter names and types
are not distinguished and are simply referred to as the“name” in this paragraph. Each of the names is treated asa single noun.
The third element is a sequence derived from themethod name using OpenNLP 1 . First, a sequence ofsimple words from the compound name of the method
is obtained. Then the parts-of-speech of each simple word
1 OpenNLP is a natural language processing system. http://opennlp.
sourceforge.net/

are determined by OpenNLP. As described in Section II-A,
headings to and new are treated as verbs.
2) Extracting V-O relation by pattern matching: Patternmatching is used to obtain a tuple <V, DO, IO> from themethod property (see Figure 2). The pattern (extraction
pattern) is composed of two parts, the structure spec andextraction spec.
The structure spec is represented by a tuple of four
elements. These four elements correspond, respectively, tothe return type, name of the method, parameters, and classname. Unlike the method property, the elements of thetuple are not sequences of words. An element of a structure
spec is a wild card or a sequence of pairs consisting of apart-of-speech and a word number.
A structure spec matches the method property only
when all of the following conditions are satisfied.
1) For each n-th element of the structure spec and themethod property, the element of the structure spec
is a wild card, or both sequences have strictly thesame part-of-speech in the same order.
2) If the structure spec has the same word number
at several points, the corresponding words in themethod property are the same.
The extraction spec is represented by a tuple of threeword numbers. The third number may be empty. If thestructure spec matches a method property, the words that
correspond to the word numbers specified in the extraction
spec are extracted as V, DO, and IO words, respectively.
If the third number is empty, IO is also empty.
Several patterns are defined by hand prior to patternmatching. The method properties obtained in the previous
stage are collated with the patterns. If two or more patterns
match a single method property, multiple tuples for eachpattern are extracted from the single method property.
C. Step 3: Filtering V-O relation
This step filters the output of step 2, and builds a
dictionary of V-O relations that frequently appear in sourcecode. In particular, only those tuples that appear in acertain number of software products are included in the
dictionary. The threshold is tuned by hand.
IV. E VALUATION E XPERIMENT
We performed an experiment to evaluate the validityof the dictionary built using the proposed method. Thissection describes the experiment in detail, together with
its result, and then examines and discusses the result.
A. Experimental setup
We prepared 31 extraction patterns by hand (Table I).
The target of extraction was source code for 37 open
source software products (see Table II). The products
were classified into four domains, Web Applications, XML
Processing, Databases, and GUIs, which are abbreviated as
Web, XML, DB, and GUI, respectively. For each domain,
source files were analyzed and a dictionary built.

Table IIIN UMBER OF METHODS AND EXTRACTED TUPLES

Web
XML
DB
GUI

# of
methods
74707
55812
74127
298696# of methods
that matchany patterns
67276
46885
60326
247918matched
ratio
90%
84%
81%
83%

# of
tuples
67429
49926
63087
273202

Table IVF REQUENCY DISTRIBUTION OF TUPLES

Web
XML
DB
GUI

# of products producing tuples
1
2
3
4
5
67147 258
184249379 465
63 13
562415 609
28
1 32
272795 339
38 23
5

6
0
1
2
2

B. Resulting dictionaries
Table III gives the output of the analysis before filtering.
Since several methods produce two or more tuples, # oftuples is greater than # of methods that match any patterns.
Table IV shows the frequency distribution of tuples
obtained from a certain number of software products.
Based on the above results, we set 2 as the thresholdfor filtering; i.e., tuples appearing in 2 or more software
products were included in the dictionaries.
C. Evaluation process
The resulting dictionaries were evaluated by 6 students
in a software engineering laboratory. The participants all
had experience in software development in Java. Moreover, they evaluated the dictionaries for the domains inwhich they had some experience.
For each domain dictionary, the tuples <V, DO, IO>
were evaluated from the following perspectives.
1) The V-O relation of the tuple is actually used in thedomain or in Java programs.
2) The verb, direct-object, and indirect-object are suitable.
3) The tuple is useful for appropriate naming of identifiers.
Based on the perspectives, we prepared several questions for the participants.
The following three questions were based on the first
perspective.
• Q1
Is this <V, DO, IO> tuple popular in the domain of
the dictionary?
• Q2Is this <V, DO, IO> tuple popular in common Java
programs?
• Q3
Is this <V, DO, IO> tuple popular in another domain? If so, give the domain.
The following question was prepared according to thesecond perspective.

Table I
L IST OF THE EXTRACTION PATTERNS

return type
*
*
*
*
*
void
void
void
void
void
void
void
void
void
void
void
void
noun1
noun1
noun1
noun1
noun1
noun1
noun1
noun1
noun1
noun1
noun1
noun1
noun1
noun1

structure spec
method nameverb1 noun2 prepos3 noun4
verb1 prepos2 noun3
verb1 noun2
verb1 prepos2 noun3
verb1 noun2 prepos3
verb1
verb1 prepos2 noun3
verb1 noun2
verb1 noun2 prepos3 noun4
verb1
verb1 noun2
verb1 noun2
verb1 noun2
verb1 noun2
noun1 verb2
noun1 verb2
noun1 verb2
verb2 noun1
verb2 noun1 prepos3 noun4
verb2 noun3 prepos4 noun5
verb2 prepos3 noun4
verb2 noun1
verb2
verb2 prepos3
verb2 prepos3 noun4
verb2 prepos3 noun4
verb2 prepos3
verb2 noun3
verb2 noun1
verb2 noun3
verb2 noun1

parameters
*
*
*
noun4
noun4
(empty)(empty)
noun2
*
noun2
noun3
noun3
(empty)(empty)
noun3
noun3
noun1
noun3
noun4
(empty)noun5(empty)
noun3
noun4
*
(empty)noun4(empty)(empty)(empty)(empty)class name
*
noun4
noun3
*
*
noun2
noun4
noun3
noun5
noun3
noun4
noun2
noun2
noun2
noun4
noun4
noun3
noun1
noun3
noun6
noun6
noun3
noun4
noun5
*
noun1
noun4
noun1
noun3
noun3
noun1

extraction spec
verb
DO
IO
verb1 noun2 noun4
verb1 noun4 noun3
verb1 noun2 noun3
verb1 noun4 noun3
verb1 noun2 noun4
verb1 noun2 (empty)
verb1 noun4 noun3
verb1 noun2 noun3
verb1 noun2 noun5
verb1 noun2 noun3
verb1 noun3 noun4
verb1 noun2 noun3
verb1 noun2 (empty)
verb1 noun2 (empty)
verb2 noun1 noun3
verb2 noun1 noun4
verb2 noun1 noun3
verb2 noun1 noun3
verb1 noun1 noun4
verb2 noun3 noun 3
verb2 noun6 noun4
verb2 noun1 noun3
verb2 noun4 noun3
verb2 noun5 noun4
verb2 noun1 noun4
verb2 noun1 noun4
verb2 noun4 noun4
verb2 noun3 noun1
verb2 noun3 (empty)
verb2 noun3 noun1
verb2 noun1 (empty)

Table IITARGET OF EXTRACTION

BBS-CS 8.0.3
Order Portal 1.2.4

JForum 2.1.8
Arianne RPG 0.80

Castor 1.3
Xalan-J 2.7.1

DOM4J 1.6.1
Xbeans 2.0.0

Axion 1.0 Milestone 2
Mckoi 1.0.3

Apache Derby 10.5.3
MyOODB 4.0.0

ArgoUML 0.28.1
vuze 4.3.1.2

BlueJ 2.5.3
LimeWire 5.4

Web Applications
JGossip 1.1.0.005
mvnForum 1.2.1
JBoss Wiki Beta2
JSP Wiki 2.8.3
XML
JDOM 1.1.1
Piccolo 1.04
Xerces-J 2.9.0
XOM 1.2.4 XPP3 1.1.4
Databases
H2 1.2.128
HSQLDB 1.8.1.1
NeoDatis 1.9.22.674
OZONE 1.1
GUIs
Eclipse Classic 3.5.1
jEdit 4.3.1

Q4 V, DO and IO are correctly extracted? If you do
not think so, identify the incorrect words.
The following three questions were based on the third
perspective.
• Q5
Should this <V, DO, IO> tuple be given as a good
example to a developer who is naming an identifier
in a program in this domain?
• Q6
Should this <V, DO, IO> tuple be given as a good
example to a developer who is naming an identifier
in a common Java program?
•Yazd Discussion Forum Software 3.0
SnipSnap 1.0b3
Saxon-HE 9.2.0.5
Xstream 1.3.1
Berkeley DB Java Edition 4.0.92
tinySQL 2.26
NetBeans 6.8

Q7
Should this <V, DO, IO> tuple be given as a good
example to a developer who is naming an identifier ina program in another domain? If so, give the domain.
The participants selected answers for Q1, Q2, Q5 andQ6 from (A) strongly agree, (B) agree, (C) disagree, (D)strongly disagree, or (Z) no idea.
Each of the dictionaries was evaluated by two participants, and each of the participants evaluated two different
dictionaries. 15 tuples that appeared in three or more
software products and 15 tuples that appeared in two
software products were evaluated by the participants. The•

Table V
R ESPONSE TO Q1

Web
XML
DB
GUI

(A)
21
44
32
42

(B)
35
18
36
26

(C)
7
5
4
9

Table VIIIR ESPONSE TO Q4
(D)
3
7
9
6

(Z)
24
16
9
7

wrong
verb
3
5
1
8

Web
XML
DB
GUI

Table VI
R ESPONSE TO Q2

Web
XML
DB
GUI

(A)
16
15
22
32

(B)
29
11
13
37

(C)
10
17
32
9

wrong
DO
1
7
6
1

wrong
IO
3
1
5
0

two or morewrong words
6
12
11
9

Table IXR ESPONSE TO Q5
(D)
30
42
17
6

(Z)
5
5
6
6

tuples were randomly and exclusively selected from thedictionary. However, since the dictionary for the web
application domain only contains 24 tuples appearing inthree or more products, only 6 tuples were evaluated by
two participants.
D. Results of the evaluation
First, we describe the results obtained according toperspective 1.
Table V gives the results for Q1, and Table VI the resultsfor Q2. The sum of the percentages of (A) strongly agreeand (B) agree is 62% to 75% for Q1, and 38% to 76%
for Q2. These results show that the greater part of thedictionaries consist of domain specific relations. However,
several domain independent relations are also included.
Table VII gives the responses for Q3. All dictionaries
contain some V-O relations from another domain. The
dictionary could be improved by separating these relations
into another dictionary.
Next, we give the results for perspective 2. Table VIII
gives the responses for Q4. The percentage of tuples withincorrect V, DO, or IO values varies between 6% and 13%.
This indicates that the 31 extraction patterns we prepared
could be improved.
Finally, we present the results for perspective 3.
Table IX gives the results for Q5, and Table X theresults for Q6. The sum of the percentages for (A) and(B) is between 53% and 71% for Q5, and between 30%
and 61% for Q6. The results for Q5 and Q1 indicate that
we need not only to improve precision of the dictionaries,
but also to select and provide the relations that developers
prefer. On the other hand, the results for Q6 show thatthe dictionaries contain many tuples that are suitableas naming examples for common Java programs. These
tuples should be separated into a domain independent
dictionary.
Table XI gives the responses to Q7. Similar to the resultsfor Q3, the responses for Q7 confirm the need to separate
these tuples into another dictionary.
1) Follow-up clarification of the results: Several tuples
were determined to be undesirable to developers, despite
the tuples being popular either in the domain or in

Web
XML
DB
GUI

(A)
19
33
35
28

(B)
32
15
29
30

(C)
11
10
10
13

(D)
4
16
10
11

(Z)
24
16
6
8

common Java programs. We asked the participants to givereasons for this. The answers are given below.
• The tuple contains uncertain words. (e.g. abbreviation)• The tuple is common sense for average developers.
• The tuple is used not in the whole domain, but in the
programs that dependent on a specific library.
E. Discussion
The results for Q2 and Q3 show that the dictionaries
contain V-O relations in another domain. The contamination might be as a result of the following two reasons.
• The threshold for filtering is too low to remove noise.
• Since software products generally span several domains, the relations in the domains covered by eachof the input products, also span several domains.
The first problem is easy to solve by increasing thenumber of input products.
Regarding the second problem, we have a solution as
described below. First, increase the number of domain
categories and input products, and then classify the products into the domain categories on a nonexclusive basis.
Thereafter, we track the origin products of the tuples. If atuple is a candidate of two or more dictionaries, the best
dictionary to include the tuple is selected based on theorigin products and their domains.
Table XR ESPONSE TO Q6

Web
XML
DB
GUI

(A)
13
14
31
29

(B)
19
13
13
26

(C)
23
12
24
15

(D)
30
46
16
13

(Z)
5
5
6
7

Table XIR ESPONSE TO Q7 ( NUMBERS IN PARENTHESES MEAN THE NUMBER
OF SAME ANSWERS )XML
DB

Data Analysis(1), GUI(1), Parser(1),Resource Management(1), Tree Structure(1),Graph Processing(1)GUI(5), Web Application(1)Table VII
R ESPONSES TO Q3 ( NUMBERS IN PARENTHESES MEAN THE NUMBER OF SAME ANSWERS )
Web
XML
DB
GUI

Database(16), I/O processing(6), Common Java Programs(2)Data Analysis(2), GUI(1), Parser(1), Resource Management(1), Tree Structure(1), Graph Processing(1)GUI(5), Web Application(1), String Processing(1)DB(1), Networking(1), Program Test Cases(1), Archiver(1), Common Java Programs(4),F. Threats to validity
From the viewpoint of the dictionary, the data assignment is performed randomly, since the tuples are
randomly extracted from the dictionaries. However, theinput software products were collected intentionally, andthe number of products may be insufficient.
Regarding the participants, they are students in a graduate school, and not professional software developers. However, since they have experience of software development
through part-time jobs or research projects, they havesufficient knowledge of several target domains to evaluate
the dictionaries. Since the number of participants was notlarge enough, we could not randomly assign participants
to dictionaries.
V. R ELATED W ORKS
This section introduces related works on V-O relationsin the source code, and the differences between theseworks and our approach.
Shepherd et al. [10] and Fry et al.[9] extracted V-O
relations from methods or comments in source code written in an object-oriented language, and used the relations
for feature location and aspect mining. Hill et al. [11]extracted the <V, DO, IO> tuples from source code andapplied the tuples to feature location and aspect mining.
Our approach is to build domain-specific dictionaries
suitable for providing identifier names.
Høst et al. built a dictionary of verbs from the name andbody of methods [12], and created several naming rules
from the dictionary to detect and fix incorrect naming[13].
Our approach is more relaxed compared to that in [13];many good examples can be obtained using a verb withan associated object.
VI. C ONCLUSION AND F UTURE W ORKThis paper proposed an approach for building a domain
specific dictionary of verb-object relations. The entries inthe dictionary, i.e. tuples consisting of <V, DO, IO>, areextracted from identifiers related to a method.
As a future work, we aim to improve the precision of thedictionaries and to build larger dictionaries from a larger
set of source code files. To support naming of identifiers, asystem is needed that can suggest an example name to thesoftware developer in the context of the source code. To
help achieve good naming, visualization of the dictionaries
is helpful for developers who have little experience in
certain domains.
ACKNOWLEDGEMENT
This work was supported by KAKENHI (21700031).

R EFERENCES[1] R. K. Fjeldstad and W. T. Hamlen, “Application program
maintenance study: Report to our respondents,” in Proceedings GUIDE 48, April 1983.
[2] T. A. Corbi, “Program understanding: challenge for the
1990’s,” IBM Syst. J., vol. 28, no. 2, pp. 294–306, 1989.
[3] A. von Mayrhauser and A. M. Vans, “Identification of
dynamic comprehension processes during large scale maintenance,” IEEE Trans. Softw. Eng., vol. 22, no. 6, pp. 424–
437, 1996.
[4] N. Pennington, “Comprehension strategies in programming,” in Empirical studies of programmers: second workshop. Norwood, NJ, USA: Ablex Publishing Corp., 1987,
pp. 100–113.
[5] D. Lawrie, C. Morrell, H. Feild, and D. Binkley, “What’s ina name? a study of identifiers,” in ICPC ’06: Proceedingsof the 14th IEEE International Conference on Program
Comprehension. Washington, DC, USA: IEEE Computer
Society, 2006, pp. 3–12.
[6] Y. Hayase, M. Ichii, and K. Inoue, “A novel approachfor building a thesaurus for program comprehension (inJapanese),” in Proceedings of winter workshop 2008 in
Dogo, no. 3, 2008, pp. 33–34.
[7] Oracle Corporation, “The java tutorials,” http://java.sun.
com/docs/books/tutorial/java/javaOO/index.html.
[8] Sun Microsystems, “Java platform, standard edition 6 API
specification,” http://java.sun.com/javase/6/docs/api/.
[9] Z. P. Fry, D. Shepherd, E. Hill, L. Pollock, and K. VijayShanker, “Analysing source code: looking for useful verb–
direct object pairs in all the right places.” IET Software,
vol. 2, no. 1, pp. 27–36, 2008.
[10] D. Shepherd, L. Pollock, and K. Vijay-Shanker, “Towards
supporting on-demand virtual remodularization using program graphs,” in AOSD ’06: Proceedings of the 5th international conference on Aspect-oriented software development.
New York, NY, USA: ACM, 2006, pp. 3–14.
[11] E. Hill, L. Pollock, and K. Vijay-Shanker, “Automatically
capturing source code context of NL-queries for software
maintenance and reuse,” in ICSE ’09: Proceedings of the2009 IEEE 31st International Conference on Software
Engineering.
Washington, DC, USA: IEEE Computer
Society, 2009, pp. 232–242.
[12] E. W. Høst and B. M. Østvold, “The programmer’s lexicon,
volume i: The verbs,” in SCAM ’07: Proceedings of theSeventh IEEE International Working Conference on Source
Code Analysis and Manipulation. Washington, DC, USA:IEEE Computer Society, 2007, pp. 193–202.
[13] ——, “Debugging method names,” in Genoa: Proceedings of the 23rd European Conference on ECOOP 2009
— Object-Oriented Programming.
Berlin, Heidelberg:
Springer-Verlag, 2009, pp. 294–317.