JP6568605B2 - 大規模ソースコードリポジトリにおける自動インポートおよびディペンデンシー - Google Patents

Description

背景
開発者は、外部コードまたはライブラリを組み込んだ複雑なソフトウェアアプリケーションをビルドすることが多い。たとえば、開発者は、人のリストを自分のアプリケーションに含めようとすることがある。開発者は、自分自身のリストオブジェクトを定義する代わりに、外部パッケージからリストクラスを含めることがある。図１に示すようなこの例では、開発者は、自分のコード内の標準ライブラリから、「java.util.List」などのリストを含めることがある。「java.util.List」は、java.utilパッケージを通じて公的に利用可能な、順序付けられたコレクションのクラスである。リストが開発者のソースコードファイルにインポートされると、開発者は、リストがインスタンス化されるまたは使用される場合はいつでも、完全修飾名「java.util.List」を用いる必要はなく、リストを単に単純名「List」で参照することが可能になる。たとえば、図１の３行目で、コードは、修飾名「java.util.List」ではなく、ただ単に単純名「List」を参照する。

パッケージ、ライブラリ、または修飾名を定義する外部コードをソースコードにインポートするプロセスは、標準統合開発環境（ＩＤＥｓ: integrated development environments）を用いた小規模なコードベースにとっては簡単であり得るが、大規模なコードベースは、標準的なＩＤＥｓが修飾名と呼ばれる適切な完全名、またはディペンデンシーに関して適切なビルドシステム構築物を効率的に探索するには、あまりに多くの外部ディペンデンシーを有している。

従来のシステムは、全コードベースを眺めて適切なパッケージ、ライブラリ、または他の外部コードを決定しようとすることによって、リアルタイムで修飾名を探索しようとする。このプロセスは時間がかかる。大量のソースコードをこのアプローチを用いて妥当な時間で処理することはどうしてもできない。

発明者によって認識されているように、ソースコードに存在する単純名の参照および修飾名を設けるビルドシステムディペンデンシーに関して適切なパッケージ、ライブラリ、または外部コードをインポートするために、修飾名の候補を素早く探索することが望ましいであろう。

概要
本明細書は、ソースコードファイル、たとえばＪａｖａ（登録商標）言語のソースコードファイル内の少なくとも１つの単純名の修飾名の候補を探索することに関する技術を説明する。

一般に、本明細書で説明される主題の一態様は、ソースコードファイル内の少なくとも１つの単純名の修飾名の候補を探索するためのシステムにおいて具体化できる。システムの例は、１つ以上の処理装置と、方法の例を実現する命令を格納する１つ以上の記憶装置とを備え得る。方法の例は、対応する修飾名が求められている少なくとも１つの単純名を有するソースコードファイルを受信するステップと、ソースコードファイルをパースしてファイル内の単純名およびファイル内の修飾名を決定するステップと、対応する修飾名が必要とされる少なくとも１つの単純名に関して、ソースコードグラフを検索して少なくとも１つの単純名に対応する、可能性のある修飾名を検索するステップと、ソースコードグラフから可能性のある候補修飾名のリストを受信すると、リストを出力するステップとを含み得る。

これらおよび他の実施形態は、以下の特徴のうちの１つ以上を任意に含み得る。可能性のある候補修飾名のリストを、リストの出力に先立って、付加情報でフィルタリングまたはエンリッチメントし得る。修飾名が選択されると、特定の修飾名に関するビルドディペンデンシーおよびビルドターゲットを決定し得る。リストの出力に先立って特定の種類の修飾名が他のソースコードファイルによって使用された回数に基づいて、可能性のある候補修飾名のリストのフィルタリングを行ない得る。特定の修飾名がソースコードリポジトリの他の部分において使用された頻度に基づいて、リストのランク付けを行ない得る。リストが１つの可能性のある修飾名しか含まない場合、ユーザの対話なしで当該名前を修飾名として自動的に選択し得る。ユーザが可能性のある候補修飾名のリストから修飾名の選択を受信するように、インターフェースを提供し得る。フィルタリングは、修飾名に対応する可能性のある単純名が現在参照されているソースコードファイルから修飾名パッケージが可視であるかどうかを判断することと、修飾名パッケージがソースコードファイルから可視であるという判断に応じて、修飾名パッケージの名前を可能性のある候補修飾名として設けることとを含み得る。フィルタリングは、ソースコードファイルのビルドのために、時間またはリソースの増加を含む、修飾名パッケージがビルドプロセスに追加し得るコンプリケーション量を判断することと、修飾名パッケージがビルドプロセスに追加したコンプリケーション量が適切な量であるという判断に応じて、修飾名パッケージの名前を可能性のある候補修飾名のリストに追加することとを含み得る。

修飾名と単純名とを含むソースコードの例を示す図である。 ソースコードファイル内の単純名の修飾された名前を決定するシステムの例を示すブロック図である。 コンピューティングデバイスの例を示すブロック図である。 ソフトウェアパッケージのホスティングおよびパブリッシングのために配置 されたコンピュータの例を示すハイレベルブロック図である。

詳細な説明
ある実施形態例によると、特定のソースコードリポジトリまたは複数のリポジトリについて全てのソースコードを示す分散システムには大規模グラフが存在する場合がある。ソースコードがインデックス化されてグラフを作成し得る。いくつかの実施態様では、このグラフは、グラフが個別の開発者のマシンで実行されず同時に複数の開発者によってアクセス可能になるように、開発者によってリモートアクセスされる１台または複数のマシン上に存在し得る。最もシンプルな形式において、グラフは２つの表であり得、１つの表は単純名を修飾名にマッピングし、もう１つの表は修飾名をビルドシステムディペンデンシーにマッピングする。分散システムまたはクラウド環境でグラフを作成することおよびグラフにアクセスすることによって、開発者の間で計算のキャッシュおよび再利用が可能である。他の実施形態では、グラフは開発者自身のマシン上に存在し得る。

図２に示すように、ソースコードファイルの例（２０１）には、３行目の「Ｂａｒ」と５行目の「Ｆｏｏ」という２つの単純名がある。「Ｂａｒ」の修飾名は、１行目の「com.sourcecode.Bar」としてコードに設けられている。しかしながら、「Ｆｏｏ」の修飾名は設けられていない。

システムのある例では、開発者のマシンで実行される統合開発環境（ＩＤＥ）が、特定のソースコードファイルで使用される単純名のリストを設け得るパーサ（２０３）を有し得る。また、パーサ（２０３）は、ソースコードファイル内の修飾名のリストを設け得る。図２に示すソースコードファイルの場合、単純名のリストは[Foo, Bar]となり得る。修飾名のリストは、[com.sourcecode.Bar]となり得る。図示するように、単純名に対応する修飾名は設けなくてもよい。修飾名、および対応した修飾名が設けられていないソースコード内の単純名の修飾名を設けるビルドシステム構築物を探索するために、ソースコードグラフ（２０５）に、単純名の修飾名への可能性のある拡張についてクエリし得る。示された例では、ソースコードグラフ（２０５）に、「Ｆｏｏ」の修飾名および「Ｆｏｏ」と関連付けられたビルドディペンデンシーについてクエリし得る。この例で修飾名が「Ｂａｒ」などのインポートとして設けられる場合、ビルドシステムディペンデンシーは存在するかもしれず、または存在しないかもしれない。したがって、完全修飾名がソースコードに設けられている場合であっても、ソースコードグラフ（２０５）にビルドシステムディペンデンシーについてクエリすることもある。

たとえば、「Ｆｏｏ」を探している場合、ソースコードグラフ（２０５）の検索は、名前「Ｆｏｏ」を含むクラスおよびビルドシステムアーティファクトに一致し得る。いくつかの実施形態では、結果は、単純名がコードにおいて使用される態様によってフィルタリングされる。たとえば、仮に「Ｆｏｏ」の特定の方法が呼び出されると、その方法を含まない完了に関する完全修飾の可能性のある候補が、可能性のある候補のリストからフィルタリングされ得る。その後、クエリは、インポートおよびビルドシステムディペンデンシーのリストを戻す。当業者によって理解されるように、このリストの順序付けおよびフィルタリングを行なうさまざまな方法が存在する。

ソースコードグラフ（２０５）は、ファイルで探索された単純名に関するビルドシステムディペンデンシーなどの情報を得るようにトラバースされ得る。たとえば、ソースコードグラフは、ソースコードがオブジェクトファイルにコンパイル可能になるように、ディペンデンシーのターゲットを単純名「Ｆｏｏ」の修飾名に設けることが可能である。

ソースコードグラフ（２０５）をトラバースすることによって得られる所与の単純名の可能性のある修飾名のリストを、他のデータでエンリッチし、さらにフィルタリングすることが可能である（２１３）。エンリッチメントデータは、（ランキングを可能にするために）修飾名がリポジトリにおいて使用される回数と、修飾名が推奨しないようにマークされたかどうか、仮にマークされた場合は、何という修飾名を代わりに使用するべきかと、修飾名パッケージが現在参照されているソースコードから可視かどうか（いくつかのクラスを、意図的に特定のソフトウェアパッケージに限定し得る）と、ソースコードのビルドのために、この修飾名が、時間および／またはリソースの増加を含む、ビルドプロセスに追加可能なコンプリケーションの量とを含み得る。リストは、たとえば、特定の種類の修飾名が他のソースコードファイルによって使用された回数に基づいてフィルタリング可能である。フィルタリングは、すべての非可視クラスを除去すること、または、コード内の特定のコンテキスト内に適合しないであろうすべてのクラスを除去することも含み得る。たとえば、「Ｆｏｏ」は、ソースコードファイル内の特定の方法を呼び出し得るため、この方法を有さないすべての一致する「Ｆｏｏ」ライブラリは、可能性のある候補リストからフィルタリングされ得る。完了およびディペンデンシーの可能性のある候補のリストを検討のためにユーザ（２１５）に戻す場合、システムの例が、特定の修飾名がソースコードリポジトリの他の部分において他の開発者によって使用された頻度に基づいて、戻された結果のランク付けを行ない得る。

いくつかの実施形態では、頻繁に使用された修飾名が、開発者のソースコードファイルにおいて開発者によって最も使用される可能性のある名前である。また、他のランキングのうち、名前は、それらの使用が考慮されているソースコードファイルにとって可視であるかどうか、名前が示すクラスがソースコードファイルにおいて使用されている方法を有するかどうか、および、クラスが推奨しないものであるかどうかによって、ランク付けし得る。推奨しないクラスは、名前のランキングにおいて降格可能である。その後、ユーザ（２１５）に、コード内の特定の単純名の参照のために可能性のある修飾名候補の、エンリッチメントおよびフィルタリングされたリストを見せることが可能であり、ユーザは、単純名をつけられたオブジェクトに関する最も適切なパッケージ、ライブラリ、または他の外部コードソースを選択し得る。ユーザ（２１５）が修飾名の候補からソースコード内の単純名の適切な修飾名を選択すると、特定の修飾名に関するビルドルールディペンデンシーおよびビルドターゲットを操作するために、選択された修飾名がソースグラフ（２０５）に再び送信されてビルドシステムディペンデンシーに関する情報を取得し得る。いくつかの実施形態では、クエリが最も一致する可能性のあるインポートおよびビルドシステムディペンデンシーを戻すことしか行なわないように、完了およびビルドシステムディペンデンシーの可能性のある候補のリストをフィルタリングし得る。

図２に示すように、固有の修飾名（２０７、２０９）がソースコードグラフ（２０５）で探索されると、または、ファイル自体からパースされて（２０３）ソースコードファイル（２０１）において使用される単純名と一致すると、これらの修飾名をファイル（２０１）内に追加／インポートし得る。ソースグラフは、どのクラス／ビルドディペンデンシーが最も頻繁に使用されるかを判断するために、周期的に再作成可能である。

図３に示すような方法の例が、対応する修飾名が探索されるべき（または、要求される）少なくとも１つの単純名を有するソースコードファイルの受信と共に開始する（３０１）。その後、ソースコードファイルはパースされて、ファイル内で使用される単純名のリストおよびファイル内のすべての修飾名の別のリストを探索し得る（３０３）。対応する修飾名が探索されるべき少なくとも１つの単純名に関して、すべてのソースコードのグラフを検索して単純名の可能性のある候補修飾名を探索可能である（３０５）。いくつかの実施形態では、名前の候補リストを付加情報でフィルタリングまたはエンリッチメントし得る。このリストを、ユーザが所与の単純名の適切な修飾名を選択するためにユーザに提供し得る（３０９）。いくつかの実施形態では、１つの候補修飾名しかない場合、ユーザは修飾名を選択する必要がないこともあり、その修飾名が自動的に選択され得る。他の実施形態では、１つの候補修飾名しかない場合、ユーザは修飾名が単純名に適切に一致するものだと確かめるだけでよい。修飾名が選択されると、方法の例が特定の修飾名に関するビルドディペンデンシーおよびビルドターゲットを決定し得る。ソースコードファイル内の単純名に一致する修飾名を、ソースファイルに追加し得る。その後、ソースコードグラフは再作成されてもよく、単純名／修飾名／ビルドディペンデンシー頻度に関する情報を今後の分析において使用して、修飾名およびビルドディペンデンシーを探索可能である。

図４は、ソフトウェアパッケージのホスティングおよびパブリッシングのために配置されたコンピュータの例（４００）を示すハイレベルブロック図である。きわめて基本的な構成（４０１）において、コンピューティングデバイス（４００）は、１つ以上のプロセッサ（４１０）とシステムメモリ（４２０）とを備えることが典型的である。メモリバス（４３０）を、プロセッサ（４１０）とシステムメモリ（４２０）との間の通信のために使用できる。

所望の構成に応じて、プロセッサ（４１０）は、マイクロプロセッサ（μＰ）、マイクロコントローラ（μＣ）、デジタル信号プロセッサ（ＤＳＰ）、またはこれらの任意の組合せを含む任意の種類であり得るが、これらに限定されない。プロセッサ（４１０）は、レベル１キャッシュ（４１１）およびレベル２キャッシュ（４１２）などの１つ以上のレベルのキャッシング、プロセッサコア（４１３）、およびレジスタ（４１４）を備え得る。プロセッサコア（４１３）は、算術論理演算装置（ＡＬＵ）、浮動小数点演算ユニット（ＦＰＵ）、デジタル信号処理コア（ＤＳＰ Ｃｏｒｅ）、またはそれらの任意の組合せを含み得る。メモリコントローラ（４１６）もプロセッサ（４１０）と共に使用可能であり、またはいくつかの実施態様では、メモリコントローラ（４１５）はプロセッサ（４１０）の内部部品であり得る。

所望の構成に応じて、システムメモリ（４２０）は、揮発性メモリ（ＲＡＭなど）、不揮発性メモリ（ＲＯＭ、フラッシュメモリなど）、またはこれらの任意の組合せを含むいかなる種類でもよいが、これらに限定されない。システムメモリ（４２０）は、オペレーティングシステム（４２１）、１つ以上のアプリケーション（４２２）、およびプログラムデータ（４２４）を含むことが典型的である。アプリケーション（４２２）は、ソフトウェアパッケージのホスティングおよびパブリッシングのための方法を含み得る。プログラムデータ（４２４）は、１つ以上の処理装置によって実行されると、ソフトウェアパッケージのホスティングおよびパブリッシングのための方法（４２３）を実行する命令の格納を含む。いくつかの実施形態では、アプリケーション（４２２）をオペレーティングシステム（４２１）上でプログラムデータ（４２４）と共に動作するように配置可能である。

コンピューティングデバイス（４００）は、付加的な特徴または機能、ならびに基本構成（４０１）と任意の必要とされるデバイスおよびインターフェースとの間の通信を容易にするように、付加的なインターフェースを有し得る。

システムメモリ（４２０）は、コンピュータ記憶媒体の例である。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくは他の磁気記憶装置、または所望の情報の格納に使用可能でありコンピューティングデバイス４００によってアクセス可能な他の媒体を含むが、これらに限定されない。そのようないかなるコンピュータ記憶媒体も、デバイス（４００）の一部であり得る。

コンピューティングデバイス（４００）は、上述の機能のうちのいずれかを含む携帯電話、スマートフォン、携帯情報端末（ＰＤＡ）、パーソナルメディアプレーヤデバイス、タブレット型コンピュータ（タブレット）、無線ウェブウォッチ（web-watch）デバイス、パーソナルヘッドセットデバイス、アプリケーション向けデバイス、またはハイブリッドデバイスなどの、スモールフォームファクタ携帯用（モバイル）電子デバイスの一部として実現可能である。また、コンピューティングデバイス（４００）は、ラップトップコンピュータ構成とラップトップコンピュータでない構成との双方を備えるパーソナルコンピュータとして実現可能である。

上記の詳細な説明は、ブロック図、フローチャートおよび／または例の使用を介してデバイスおよび／またはプロセスのさまざまな実施形態を記載した。そのようなブロック図、フローチャートおよび／または例が１つ以上の機能および／またはオペレーションを含んでいる限りにおいて、当業者は、そのようなブロック図、フローチャートまたは例における各機能および／またはオペレーションは、広範囲のハードウェア、ソフトウェア、ファームウェアまたはそれの実質的に任意の組合せによって個々におよび／または集合的に実現され得るということを理解するであろう。一実施形態では、本明細書において記載される主題のいくつかの部分は、特定用途向け集積回路（ＡＳＩＣ： Application Specific Integrated Circuit）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ： Field Programmable Gate Array）、デジタル信号プロセッサ（ＤＳＰ： digital signal processor）、他の集積フォーマットを介して、またはウェブサービスとして実現され得る。しかしながら、当業者は、本明細書において開示される実施形態のいくつかの局面が、全体的または部分的に、１つ以上のコンピュータ上で動作する１つ以上のコンピュータプログラムとして、１つ以上のプロセッサ上で動作する１つ以上のプログラムとして、ファームウェアとして、または、それの実質的に任意の組合せとして、集積回路において均等に実現され得るということと、回路を設計すること、ならびに／または、ソフトウェアおよび／もしくはファームウェアのためのコードを記述することがこの開示を考慮して当業者の技能の範囲内であるということとを認識するであろう。加えて、当業者は、本明細書において記載される主題のメカニズムは、さまざまな形態のプログラムプロダクトとして配布可能であり、この配布を実際に行なうために使用される特定のタイプの非一時的な信号担持媒体にかかわらず、本明細書において記載される主題の例示的な実施形態が適用されるということを認識するであろう。非一時的な信号担持媒体の例は、フロッピーディスク（登録商標）、ハードディスクドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、デジタルテープ、コンピュータメモリなどといった記録可能なタイプの媒体と、（たとえば光ファイバケーブル、導波路、有線通信リンク、無線通信リンクなどといった）デジタルおよび／またはアナログ通信媒体のような伝送タイプの媒体とを含むが、これらに限定されない。

実質的に本明細書における任意の複数および／または単数の用語の使用に関しては、当業者は、必要に応じて、複数から単数におよび／または単数から複数に、文脈および／または用途に合わせて変更可能である。さまざまな単数／複数の並べ替えは、理解しやすいように本明細書では明白に説明可能である。

このように、主題の特定の実施形態について説明が行なわれた。他の実施形態は、以下の特許請求の範囲内にある。いくつかの場合において、請求項において記載される動作は、異なる順序で実行可能であり、なお望ましい結果を達成可能である。加えて、添付の図において示されるプロセスは、望ましい結果を達成するために、示された特定の順序または連続した順序を必ずしも必要としない。特定の実施態様において、マルチタスキングおよび並列処理が有利であり得る。

Claims (13)

1. コンパイルすべきソースコードファイル内の少なくとも１つの単純名の修飾名の候補を探索するための、コンピュータによって実現される方法であって、
   コンパイルすべきソースコードファイルを受信するステップを備え、前記ソースコードファイルは、対応する修飾名がコンパイラによって必要とされる少なくとも１つの単純名を含み、前記方法は、
   前記ソースコードファイルをパースして前記ソースコードファイル内の前記単純名および前記修飾名を決定するステップと、
   対応する修飾名が必要とされる前記少なくとも１つの単純名に関して、ソースコードグラフを検索して前記少なくとも１つの単純名に対応する、可能性のある候補修飾名を探索するステップと、
   前記ソースコードグラフから可能性のある候補修飾名のリストを受信すると、追加情報を有する、前記可能性のある候補修飾名のリストのエンリッチメントを行なうステップとを備え、前記可能性のある候補修飾名のリストのエンリッチメントを行なうステップは、 前記可能性のある候補修飾名のリストに含まれる、可能性のある候補修飾名に対応する修飾名パッケージがビルドプロセスに追加する前記ソースコードをビルドする時間の増加を判断することと、
   前記修飾名パッケージの名前を前記可能性のある候補修飾名のリストに追加することと、
   前記リストを出力することとを含み、前記方法は、
   修飾名が前記可能性のある候補修飾名のリストから選択されると、特定の修飾名に関するビルドディペンデンシーおよびビルドターゲットを決定するステップと、
   前記決定されたビルドディペンデンシーおよびビルドターゲットに基づいて前記ソースコードをコンパイルするステップと、
   を備える、方法。
2. 前記リストのエンリッチメントを行なうステップは、前記リストの出力に先立って特定の種類の可能性のある候補修飾名が他のソースコードファイルによって使用された回数を含むように前記リストのエンリッチメントを行なうことを含む、請求項１に記載のコンピュータによって実現される方法。
3. 前記リストのエンリッチメントを行なうステップは、特定の可能性のある候補修飾名がソースコードリポジトリの他の部分において使用された頻度に基づいて前記リストのランク付けを行なうことを含む、請求項１に記載のコンピュータによって実現される方法。
4. 前記リストが１つの可能性のある修飾名しか含まない場合、ユーザの対話なしで前記修飾名を自動的に選択するステップをさらに備える、請求項１〜３のいずれかに記載のコンピュータによって実現される方法。
5. インターフェースを提供して前記可能性のある候補修飾名のリストから修飾名の選択を受信するステップをさらに備える、請求項１〜４のいずれかに記載のコンピュータによって実現される方法。
6. 前記リストのエンリッチメントを行なうステップは、
   修飾名パッケージが、前記修飾名パッケージに対応する可能性のある単純名が現在参照されている前記ソースコードファイルから可視であるかどうかを判断することと、
   前記修飾名パッケージが前記ソースコードファイルから可視であるという判断に応じて、前記修飾名パッケージの名前を可能性のある候補修飾名として設けることと、
   を含む、請求項１〜５のいずれかに記載のコンピュータによって実現される方法。
7. コンパイルすべきソースコードファイル内の少なくとも１つの単純名の修飾名の候補を探索するためのシステムであって、
   １つ以上の処理装置と、
   複数の命令を格納する１つ以上の記憶装置とを備え、前記複数の命令は、前記１つ以上の処理装置によって実行されると、前記１つ以上の処理装置に、
   コンパイルすべきソースコードファイルを受信することを行なわせ、前記ソースコードファイルは対応する修飾名がコンパイラによって必要とされる少なくとも１つの単純名を含み、前記複数の命令は、さらに、前記１つ以上の処理装置によって実行されると、前記１つ以上の処理装置に、
   前記ソースコードファイルをパースして前記ソースコードファイル内の前記単純名および修飾名を決定することと、
   対応する修飾名が必要とされる前記少なくとも１つの単純名に関して、ソースコードグラフを検索して前記少なくとも１つの単純名に対応する、可能性のある修飾名を探索することと、
   前記ソースコードグラフから可能性のある候補修飾名のリストを受信すると、追加情報を有する、可能性のある候補修飾名のリストのエンリッチメントを行なうこととを備え、前記可能性のある候補修飾名のリストのエンリッチメントを行なうことは、
   前記可能性のある候補修飾名のリストに含まれる、可能性のある候補修飾名に対応する修飾名パッケージがビルドプロセスに追加する前記ソースコードをビルドする時間の増加を判断することと、
   前記修飾名パッケージの名前を前記可能性のある候補修飾名のリストに追加することと、
   前記リストを出力することと、
   修飾名が前記可能性のある候補修飾名のリストから選択されると、特定の修飾名に関するビルドディペンデンシーおよびビルドターゲットを決定することと、
   前記決定されたビルドディペンデンシーおよびビルドターゲットに基づいて前記ソースコードをコンパイルすることと、
   を行なわせる、システム。
8. 前記リストのエンリッチメントを行なうことは、前記リストの出力に先立って特定の種類の可能性のある候補修飾名が他のソースコードファイルによって使用された回数を含むように前記リストのエンリッチメントを行なうことを含む、請求項７に記載のシステム。
9. 前記リストのエンリッチメントを行なうことは、特定の可能性のある候補修飾名がソースコードリポジトリの他の部分において使用された頻度に基づいて前記リストのランク付けを行なうことを含む、請求項７に記載のシステム。
10. 前記リストが１つの可能性のある修飾名しか含まない場合、ユーザの対話なしで前記修飾名を自動的に選択することをさらに備える、請求項７〜９のいずれかに記載のシステム。
11. インターフェースを提供して前記可能性のある候補修飾名のリストから修飾名の選択を受信することをさらに備える、請求項７〜１０のいずれかに記載のシステム。
12. 前記リストのエンリッチメントを行なうことは、
    修飾名パッケージが、前記修飾名パッケージに対応する可能性のある単純名が現在参照されている前記ソースコードファイルから可視であるかどうかを判断することと、
    前記修飾名パッケージが前記ソースコードファイルから可視であるという判断に応じて、前記修飾名パッケージの名前を可能性のある候補修飾名として設けることと、を含む、請求項７〜１１のいずれかに記載のシステム。
13. コンピュータに請求項１〜６のいずれか１項に記載の方法を実行させるプログラム。