Vol.2009-SE-166 No.20
2009/11/6

情報処理学会研究報告
IPSJ SIG Technical Report

類のコードクローンだけを抽出して利用する手法も提案されている6) ．
これまでに提案されている類似ソースコード検出ツールは，それぞれが定義した「類似」

ソースコードの類似性ワークショップ開催報告の基準を満たすソースコードをすべて検出する．そのため，検索手法の評価において使われる再現率，適合率という評価指標のうち，適合率は常に 100 ％となり，複数の手法のトレー

石 尾

隆†1

山

本 哲

男†2

佐々木

ドオフなどを比較評価することが困難である．Bellon ら1) は，対象ソフトウェアに意図的

裕 介†1に複製したソースコードを埋め込み，また，コードクローン検出ツールの出力の一部を手作業で検査することで，探索対象となるコードクローン集合を決定し，6 つのコードクローン

ソフトウェアエンジニアリングシンポジウム 2009 併設ワークショップ「ソースコー
ドの類似性」の実施概要および成果について述べる．

検索技術を比較している．この方法は，ツールごとの検出の差異を調べるために効果的であったと考えられるが，どのようなソースコードが検出されるべきであるか，という点については明示されていない．

A Report on the Japanese Workshop on
Source Code Similarity 2009

本ワークショップは，ソフトウェア工学の中でもプログラム解析技術の研究者を中心に，類似したソースコードとはどういうものかを明らかにすることを目的として開催した．互い

Takashi Ishio,†1 Tetsuo Yamamoto†2に類似していると思われるソースコードの候補を著者らが事前に列挙しておき，それらが似

and Yusuke Sasaki†1ているか否かを参加者が手動で分類していく共同作業を実施した．
本稿は，ワークショップで得られた成果物を分析し，その結果を共有することを目的とす

This paper reports the result of the Japanese Workshop on Source Code
Similarity co-located with Software Engineering Symposium 2009.

る．原稿にすべてのデータを掲載することはできないため，使用したソースコードや参加者が記載した回答用紙などの詳細なデータについては，ワークショップウェブサイト10) に掲載しているものを参照していただきたい．以降，2 節ではワークショップにおける共同作業の実施手順を説明し，3 節にてその成果物の分析結果を解説する．4 節には妥当性への脅威

1. は じ め にについての考察を，5 節には，今後，同様の共同作業型ワークショップを計画する際に役立ソフトウェア工学分野において，類似したソースコードを検出するための技術や，それをつと思われる情報を整理した．最後に，6 節にまとめを述べる．

利用したソフトウェア開発支援手法が数多く研究されている．たとえば，コードクローン検2. 共同作業の実施手順

出手法3) やそれを利用したリファクタリング支援7) ，開発者が編集中のソースコードに似たコード片を見本として提示する手法8) などが挙げられる．しかし，種々の研究において，2.1 アンケートに基づく参加者のグループ化

発見するべき類似したソースコードの定義はそれぞれ異なっている．Coady らは，多数の参加者には，ワークショップのポジションペーパーとして事前アンケートへの回答を投稿

コードクローン検出技法について，それらの手法の特徴と違いを整理している4) ．また，定してもらった．このアンケートは 11 組のソースコードを例示しており，それらをリファク

義が異なる複数のツールから得られたコードクローン情報の差分を計算することで，望む種タリングすべきか，一方でバグが発見されたときに他方もまた調査すべきか，といった 4
つの観点と，著者の研究独自の観点からソースコードが類似していると考えるかどうかを，†1 大阪大学 大学院情報科学研究科
Graduate School of Information Science and Technology, Osaka University†2 立命館大学 情報理工学部
College of Information Science and Engineering, Ritsumeikan University

yes/no によって回答する方式となっている．
アンケートの結果を参考に，この時点で判明していた参加予定者 16 名を 4 名ずつ 4 グ
ループに分けた．グループ参加者が議論で発言しやすくなるように，以下の基準を設けた

1

c 2009 Information Processing Society of JapanVol.2009-SE-166 No.20
2009/11/6

情報処理学会研究報告
IPSJ SIG Technical Report

事前のグループ分けを行っておき，会場で当日参加者 2 名および遅刻者に対する微調整をのすべてのクラスと互いに類似しているとは限らない．

行った．

Twigi は，2 つのクラス C1 , C2 について以下のすべての条件が成り立つとき，2 つのク• 同一所属の参加者は，可能な限り別グループに入れる．

ラスが互いに類似していると判定する．なお，各条件において使用されるクラス名について• 学生が所属するグループには，アンケート回答の類似度が近い教員を最低 1 人入れる．

は，そのパッケージ名を無視して，クラス名が同一であれば同じクラスを指しているものと• アンケート回答の類似度が低い者同士は同じグループに入れない．

して扱う．また，条件の定義に登場する集合間の類似度 sim と数値間の類似度 D の算出

なお，アンケート回答の類似度には，単純なハミング距離を用いた．参加者 2 名の間で，方法については後述する．

ソースコード 11 組それぞれについて 4 つの観点で答えられた yes/no の回答が一致した割• C1 , C2 のいずれも，最も外側で定義されたクラスである（内部クラスではない）．

合を計算した．アンケート回答は，平均で約 75 ％が一致しており，最も類似度が低かった• C1 , C2 のいずれも，同名のクラスを継承している．

参加者の組で 4 割の一致，最も類似度が高かった組で 9 割の一致となっていた．

• C1 , C2 の名前が，単語列を CamelCase 形式（数字，$やアンダースコアなどの記号も参加者のソフトウェア開発経験には個人差が大きい．学生の参加者は，研究等のための開単語区切りと考える）で連結したものと仮定したとき，C1 と C2 に少なくとも 1 つの発経験が 2 年から 3 年程度であり，教員の参加者は，10 年から 20 年程度であると回答し共通の単語が含まれている．

• クラス C で宣言された private ではないメソッドのシグネチャ集合を M ethods(C) とている．また，参加者全員が C 言語または Java を使用したことがあるが，Java の開発経したとき， sim(M ethods(C1 ), M ethods(C2 )) ≥ x である．

験を明示的に回答しているのは 9 名であった．Java のソースコードの意味を理解すること• クラス C で宣言された private ではないフィールドのシグネチャ集合を F ields(C) とに関しては問題は少ないが，Java の細かい言語仕様については理解に差があると考えられしたとき， sim(F ields(C1 ), F ields(C2 )) ≥ x である．

る．参加者の多くはプログラム解析技術を研究しており，研究対象として Java を解析して• クラス C で宣言された private ではないコンストラクタのシグネチャ集合を Cons(C)いる者，つまり言語仕様の多くを知っているであろう参加者は各グループに最低 1 名，最大としたとき，sim(Cons(C1 ), Cons(C2 )) ≥ x である．なお，コンストラクタは戻り値

3 名含まれている．
2.2 題材となるソースコードの準備
本ワークショップで使用したソースコードは，ソースコード部品グループ化ツール Twigiと名前を持たないので，シグネチャ情報とは引数列の情報のみである．
9)• クラス C が呼び出すメソッドとコンストラクタの集合（コンパイル時の静的な呼び出とコードクローン検出ツール CCFinderX2) を用いて抽出した．第 3 著者がツールを適用

し先）を Calls(C) としたとき，sim(Calls(C1 ), Calls(C2 )) ≥ x である．

• クラス C の定義の開始から終了までに出現するすべての型名の集合から C 自身を除してソースコード 59 組を選び出し，その中から第 1 著者が以下の基準にしたがってソースいたものを T ypes(C) としたとき，sim(T ypes(C1 ), T ypes(C2 )) ≥ x である．

コード 36 組を選出した．

(1)

同一の要因で類似していると判定された組は代表 1 組だけを残す．たとえば A と B，

• ク ラ ス C の ソ ー ス ファイ ル に 出 現 す る 全 ト ー ク ン 数 を len(C) と し た と き ，A と C，B と C がそれぞれクラス名だけの違いにより類似していると判定されたとD(len(C1 ), len(C2 )) ≥ x である．ここでのトークンとは，ソースコードの字句解析のき，代表 1 組だけを残す．

(2)単位のことで，空白文字によって区切られた文字列である．

• クラス C のソースファイルに出現する全トークンの種類数 kind(C) に対して，

ソースコードを印刷するため，ソースコードが短いものを優先する．

D(kind(C1 ), kind(C2 )) ≥ x である．トークンの種類とは，抽象構文木におけるノー

Twigi は，引数として，グループ化する部品に要求する類似度（0 から 1 の範囲の実数値）の閾値 x を取り，与えられた Java クラスの集合を「類似した」クラスのグループへドの種類である（たとえば「識別子」は 1 種類のノードである）．
上記の条件で使用されている集合の類似度 sim は，集合 S の要素数を |S| と表記すると分解する．2 つのクラス C1 , C2 が類似していると判定されれば，それら 2 つのクラスを同一のグループに所属させる．あるグループに所属するクラス C からみると，グループ内と，次の式で表現できる．

には少なくとも１つ，C と類似していると判定されるクラスが存在するが，グループ内部

2

c 2009 Information Processing Society of JapanVol.2009-SE-166 No.20
2009/11/6

情報処理学会研究報告
IPSJ SIG Technical Report
表1

ワークショップのプログラム．

予定時刻

実際の時刻

内容

10:00-10:10
10:10-12:00

10:00-10:10
10:10-11:30
11:30-12:00
13:00-17:00
17:05-17:30

オープニング
自己紹介およびポジションペーパー紹介（5 分/人）
共同作業内容の事前説明
共同作業
議論およびクロージング

13:00-16:20
16:30-17:30

表 2 に示す．この割当ては，閲覧の順序が結果に影響しないよう，どの 2 つのソースコー
ド群の組についても，2 グループごとに閲覧順序が入れ替わるようにしている．参加者のグ
ループ分けには人為的な判断が加わっているが，グループ A, B, C, D という記号の割当て自体はランダムに行った．
各グループには，6 組のソースコードを 1 部ずつ，その差分を対照できるよう着色して印刷した紙を配布した．ソースコードの差分の印刷には，WinMerge5) というソフトウェアを

表2
セッション

1
2
3
4
5
6

A
P
Q
S
R
T
U

B
Q
R
P
S
U
T

グループのソースコード閲覧順序．

C
R
S
Q
P
U
T

D
S
P
R
Q
T
U

用いた．また，参加者が持参したノート PC 上でキーワード検索等を行えるよう，ソース

備考

コードの組 (.java ファイル) と diff コマンドの出力結果，印刷した紙と同一の PDF ファグループ A のうち 1 名は参加できなかった．

イル，WinMerge のバイナリを会場にて配布した．
各グループは，与えられた 6 組のソースコードを自由な順序で読解し，以下の手順で類似

ここまで時間内に閲覧した．

性の判定を行った．

実際は閲覧しなかった．

• ソースコードが類似しているかどうか，1 人ずつ個人での判定結果を回答用紙に記述する．

sim(S1 , S2 ) = min(• グループのメンバー全員の判定結果を相互に確認し，判断の理由を述べ，議論を行う．

|S1 ∩ S2 | |S1 ∩ S2 |
,
)
|S1 |
|S2 |

• 再度，各個人の判定結果を回答用紙に記述する．
この手順により，各参加者の最初の意見と，グループでの討論によって注目された要素をまた，トークン数および種類数の類似度 D は，次のように求める．

D(v1 , v2 ) =記録することを目指した．

min(v1 , v2 )max(v1 , v2 )2.4 作業コンテキストの設定

本ワークショップにおけるソースコードの選択では，オープンソースソフトウェアの集合に参加者は，ソフトウェア部品の再利用を支援するために，ソースコード検索エンジンを構対して様々な閾値で Twigi を適用し，類似度の閾値を x < 1 でグループ化されるが x = 1 で築する立場に立っているものとした．構築するシステムは，いわゆるキーワード検索によはグループ化されない（完全には一致しない）クラスの組を抽出した．また，CCFinderX2)

り，対応するソースコードをランキング表示すると仮定する．このようなシステムが提示すによる部品の抽出では，同様のソースコード集合に対してクローン検出を適用し，他のソー

るべきソースコードをデータベースに蓄積するためにインターネット上からソースコードをスファイルとの間でコードクローンになっているコードの割合（RSA）が 0.8 以上のものを収集してきたとき，互いに類似したソースコードが存在する可能性がある．
参加者は，与えられた組のコードが実際に収集された場合にどうするべきかを，以下の中抽出した．

2.3 ソースコード閲覧の手順から選択して回答する．

本ワークショップで予定していたプログラムと，実際の時間を表 1 に示す．共同作業セッ(a) 一方のみを残す． 一方だけを登録し，他方は登録しない．

ションが長引いたことから，予定よりも議論時間が短くなった．共同作業では，参加者が(b) 集約する． 2 つのソースコードを 1 部品に集約して登録する．検索結果のランキング

適宜休憩を取れるよう，全体の作業時間を 30 分から 45 分程度の「セッション」に分解し，には 1 部品として提示され，利用者は集約後のソースコードと元の 2 つのソースコー

1 セッションに一群のソースコードを評価していくという方式を採用した．ソースコード 1

ドを閲覧可能とする．この集約方法については厳密に規定していなかったが，リファク組に対する判断に必要な時間を 5 分と見積もり，用意した 36 組のソースコードをランダムタリングによる共通の親クラスの抽出や，共通ソースコードのテンプレートと差分パッに 6 組ずつに分解し，P, Q, R, S, T, U とした．各グループへのソースコードの割当てをチを想定していた．

3c 2009 Information Processing Society of JapanVol.2009-SE-166 No.20
2009/11/6

情報処理学会研究報告
IPSJ SIG Technical Report
表 3 参加者別の回答数．
参加者 ID

立場

A1
A2
A3
A4
A5
B1
B2
B3
B4
B5
C1
C2
C3
C4
D1
D2
D3
D4
計

教員
学生
教員
学生
企業
教員
学生
学生
教員
学生
教員
学生
学生
教員
教員
教員
教員
教員

a
0
0
0
0
0
5
4
9
11
10
2
2
1
1
3
7
2
5
62

b
3
2
0
1
0
5
5
2
3
5
13
14
13
13
2
1
8
0
90

c
11
20
22
23
22
7
9
7
6
7
7
6
8
6
12
10
11
12
206

d
4
2
2
0
2
6
6
6
4
2
2
2
2
4
7
6
3
7
67

は 2 つの選択肢に固まっており，平均では 1.55 個の選択肢が選ばれている状況であった．

備考

これは，意見が近い参加者を同一グループに含めたことが影響していると思われる．

第 2 セッションから参加．

今回収集した 426 の回答のうち，判断が議論の途中で変更されたのは 109 回で，1 人あたり最低 1 回，最高で 11 回の判断変更を行っていた．変更理由には様々なものがあるが，グループ参加者の意見を聞いてその意見に賛同した，あるいは自分の誤解に気付いて意見を修正したという理由などが見られた．グループでの議論により，参加者がより正しいと感じた回答を獲得できたと考えられる．

3.1 ソースコードの分類結果
本項では，各選択肢を選んだ参加者の意見を整理する．

(a) 一方のみを残すソースコード．(a) の判断が多数回答されたソースコードの組では，ソースコードの文面がよく似ており，対処法という点では意見が分かれるが，少なくとも何らかの関連が見出されている（選択肢 (d) が選ばれていない）．そのようなコードの代表例
である P1 は，異なるパッケージに存在する同名のクラスである．一方のファイルでは，同じパッケージに存在するインタフェースを参照しているが，他方では，同名のインタフェー
スを内部クラスとして定義している．また，やはり (a) が多数選択されている S1 は，パッケージ名とインデントのみが異なるソースコードの組である．これに対して，機能が十分に近ければどれか１つだけを残していれば十分である，インデントの差異のみであれば集約す(c) 関連リンクを登録する． 2 つのソースコードはそれぞれ個別の部品として登録するが，る価値がない，という理由から (a) が選択されている．

関連リンクを登録しておく．検索システムは，利用者が部品を見ているとき，関連部品情報の提示を行う．

(a) 以外の選択肢を選んだ参加者の意見としては，ソースコードの大部分が一致していても，ソースコードを捨てることによりパッケージ名やコメントなどの検索キーとなりうる情(d) 個別の部品として登録する． 2 つのソースコードには強い関連がなく，それぞれを個報や，開発者の「意図」が失われる可能性があるとの指摘があった．また，ソースコードの別の部品として取り扱う．

パッケージ名などからライブラリ名を知り，そのライブラリ全体を再利用するという再利用

回答用紙には，選択肢とともに，その選択理由を記載してもらった．

経路が失われるという指摘もあった．ホワイトボックス再利用のように，部品のソースコー

3. 実 施 結 果

ドを確認する開発者にとっては，同じ部品が重複して登録されていないほうが利便性は高まるなど，再利用形態まで考慮すべきではないかという意見が出た．

回答を参加者別に集計したものを表 3 に，ソースコード別に集計したものを表 4 に示す．
表 4 における抽出方法の列では，使用した Twigi の閾値を示している．Twigi 0.85 という(b) 集約するソースコード．本ワークショップでは，集約という言葉の意味を厳密に規定

記述は，閾値 x = 0.85 ではこれらのクラスが同じグループに含まれるが，閾値を 0.05 増や

していなかったため，グループごとに判断は異なるが，Java のリファクタリングの概念にした x = 0.90 では別のグループになったことを示している．つまり，そのグループのファ強く影響されいる．
「親クラスとして抽出するべき」「パッケージ名だけが異なるソースコー

イル間の類似度が 0.85 以上 0.90 未満であったことを意味する．

ドの組は Java の言語仕様上はまとめられないので (b) にはできない」など，具体的な集約

表 3 から，グループおよび参加者によって判断に偏りがある様子を知ることができる．1

方法まで考慮した意見が見られた．また，集約の結果が検索にどのように使用されるか分かつのソースコードに対して 1 グループの意見だけに注目すると，多くの場合は 1 つあるいらない，再利用データベースの構築という観点では部品の集約が将来の保守における利益に

4

c 2009 Information Processing Society of JapanVol.2009-SE-166 No.20
2009/11/6

情報処理学会研究報告
IPSJ SIG Technical Report
表4
ソース ID

抽出方法

P1
P2
P3
P4
P5
P6
Q1
Q2
Q3
Q4
Q5
Q6
R1
R2
R3
R4
R5
R6
S1
S2
S3
S4
S5
S6

Twigi 0.95
Twigi 0.90
Twigi 0.90
Twigi 0.85
Twigi 0.90
CCFinderTwigi 0.90
Twigi 0.85
Twigi 0.90
Twigi 0.95
Twigi 0.95
Twigi 0.90
Twigi 0.85
Twigi 0.95
Twigi 0.90
Twigi 0.85
Twigi 0.95
Twigi 0.85
Twigi 0.95
Twigi 0.90
Twigi 0.85
Twigi 0.90
Twigi 0.85
Twigi 0.50

ソースコードの特性と分類結果．

比較されたクラス（2 つ目のクラスのパッケージ名は，1 つ目と同一の場合省略）

com.adito.applications.server.IOStreamConnector，com.maverick.multiplex.IOStreamConnector
org.apache.commons.javaﬂow.bytecode.transformation.asm.ResumeTestCase，InvokerTestCaseorg.apache.commons.lang.builder.DefaultToStringStyleTest，StandardToStringStyleTestorg.eclipse.swt.opengl.examples.GradientTab，FogTaborg.apache.commons.lang.mutable.MutableIntTest，MutableLongTest
portal.presentation.messenger.mmsg msgfaxmain，mmsg msgicqmainorg.eclipse.ui.actions.TextActionHandler，org.eclipse.ui.internal.navigator.TextActionHandlerorg.eclipse.jdt.internal.ui.preferences.CodeAssistPreferencePage，CodeAssistAdvancedPreferencePageorg.apache.commons.io.ﬁleﬁlter.PreﬁxFileFilter，SuﬃxFileFilter
phex.common.collections.IntSet，org.limewire.collection.IntSetorg.eclipse.core.tools.resources.metadata.MarkersDumpingStrategy 1，MarkersSnapshotDumpingStrategy 1
org.apache.commons.net.smtp.SMTPConnectionClosedException，org.apache.commons.net.ftp.FTPConnectionClosedExceptionorg.eclipse.swt.browser.DownloadFactory，ExternalFactory
com.adito.security.itemactions.DisableAuthenticationSchemeAction，EnableAuthenticationSchemeActionorg.agilewiki.elementmodel.wholeness.roots.updatecommands.DumpCommandRoot ，LoadCommandRootorg.eclipse.jdt.internal.debug.eval.ast.instructions.OrOperator，AndOperatororg.apache.commons.io.ﬁleﬁlter.OrFileFilter，AndFileFilterorg.apache.commons.jxpath.ri.model.jdom.JDOMNamespacePointer，org.apache.commons.jxpath.ri.model.dom.NamespacePointercom.adito.security.pki.SimpleASNWriter，com.maverick.util.SimpleASNWriterorg.apache.commons.io.output.PackageTestSuite，org.apache.commons.io.input.PackageTestSuiteorg.eclipse.ui.internal.ide.StringMatcher，org.eclipse.ui.views.navigator.StringMatcherorg.eclipse.core.internal.commands.operations.GlobalUndoContext，org.eclipse.core.commands.operations.UndoContext
org.eclipse.jdt.internal.ui.viewsupport.LibraryFilter，org.eclipse.jdt.internal.ui.ﬁlters.ContainedLibraryFilterorg.eclipse.swt.internal.motif.XAnyEvent，XConﬁgureEvent

a
9
2
2
0
5
2
1
7
0
7
1
1
5
1
0
0
1
2
9
1
3
1
2
0

b
4
4
0
0
5
11
3
8
8
2
1
4
6
8
5
4
1
0
4
2
7
1
0
2

c
4
10
11
4
7
4
14
3
10
9
16
5
6
9
9
14
16
16
5
5
8
5
12
4

d
0
1
4
13
0
0
0
0
0
0
0
8
0
0
4
0
0
0
0
10
0
11
4
12

備考
遅刻者のデータなし．
同上．
同上．
同上．
同上．
同上．

「判断できない」1 名．

は，いずれも，機能がきわめて類似しているが同一ではなく，かつ，ソースコードの差分もつながらないといった理由から，(b) は選びにくいという指摘があった．

非常に小さいという特徴があったといえる．

このような状況に影響されてか，共通部品を作成して登録すべきである，という意見が多数派となったソースコードは比較的少ない．P6 は，使用している文字列リテラルの fax(c) 関連リンクを登録するソースコード．2 つのソースコードの関連リンクだけを登録しと icq という部分だけが異なっているコードの組である．Q3 は，ファイル名に対してそのておくという選択肢は，(a) や (b) と比べて情報を失うリスクがないことから，全回答のうPrefix あるいは Sufix のどちらを検査するかが異なっている．そのため，コメントおよ

ち約半数の 206 個の回答が (c) という結果となった．なお，関連リンクとして，どのよう

び変数名の prefix と sufix を入れ替え，また，メソッド呼び出し checkStartsWith とな種類の関連を与えるのかは規定していなかったため，参加者ごとに，たとえば派生関係や

checkEndsWith を入れ替えるだけで，一方から他方へと変換できる．R2 は，Disabled とバージョンの新旧など，単なる検索用のリンク以外を想定して，違う意味で同じ判断 (c) にEnabled という対になったクラスであり，isEnabled メソッドの戻り値の真偽が反転してなっている可能性がある．

いるほかは，クラス名と文字列リテラルに出現する Enable と Disable が入れ替わってい(c) が多数派となった P2 は JUnit テストの組で，異なる TestSuite クラスの名前をるだけとなっている．S3 は，コメントの英単語の綴りが一方では誤っており他方では正し

JUnit に与える役割を持っている．P3 は，同じパッケージに含まれている JUnit テストのいなどの特徴がある組で，同一ソースコードの異なる版である可能性が推測される．これらための 2 つのクラスで，テストに用いる引数の値や出力文字列が異なるほか，作成した時期

5

c 2009 Information Processing Society of JapanVol.2009-SE-166 No.20
2009/11/6

情報処理学会研究報告
IPSJ SIG Technical Report
表5が異なるためかライセンス表記にも違いがみられる．これらのコードは，単純には，テスト

回答用紙に出現した単語．

という同じ役割に所属していると考えることができるが，同一機能ではないために集約や破合計出現回数

使用人数

単語カテゴリ単語

棄は難しく，関連リンクを作るという選択肢になったと思われる．その一方で，作られた時

40
31
28
25
22
16
14
13
10
7

10
12
9
14
7
4
9
5
6
5

バージョン管理
クラス階層
クラスの関係
テスト
ロジック
コード例
コメント
識別子
役割
振舞い

バージョン (16)，版 (7)，派生 (8)，新 (8)，オリジナル (1)継承 (5)，extends(5)，子 (13)，親 (8)対 (28)
テスト (25)
ロジック (14)，アルゴリズム (8)例 (6)，サンプル (5)，example(5)コメント (3)，Javadoc(11)識別子 (9)，名 (4)役割 (10)
振舞い (7)期が異なるファイルには互いに関連があるとは思えない，という意見もあった．

Q1 と Q5 は，参照する定数が異なるクラスの組である．Q1 では，異なるクラスに定義された同名のフィールドを参照しており，一方で super(C1.Delete); という定義があれば，他方では super(C2.Delete); というように，参照先だけが異なっている．

R4 と R5 は，論理演算子 AND と OR に相当する処理をプログラム中で計算するためのクラスの組である．使用する論理演算の違いや，実装上の細かい違い以外の構造はほとん
ど同じである．これらのコードは集約は困難であるが，対となる機能を実装したと想像することができたことから，(c) が選ばれたと考えられる．

これらの内容を分析した結果，参加者がソースコードの類似性を判断した基準には，以下の項目が含まれていると考えられる．

(d) 個別の部品として登録するソースコード．目的が異なる，あるいは，検索として個別識別子の類似性． グループ A，B は，使用されている識別子が似ているソースコードにはに提示されるほど強い関係がないと判断されたソースコードは，(d) と判定されていた．

P4 は，opengl パッケージを使用するプログラム例の組である．画面への描画を行う構関連がありそうだと考えていた．

造自体は同一であるが，描画用の処理には異なる機能を使用しており，それらはまったく個クラスの振舞いの類似性． 振舞いがまったく同じであれば，集約する必要はなく一方だけ別のものであると判断されている．

を使用すればよい，あるいは，実装例として 1 つあればよいという意見があった．特Q6 は，例外クラスの組である．特別な機能を持たない例外クラスであるので，所属パッに動作を分析していたのはグループ C で，コメントはあまり参考にしなかったとイン

ケージ，クラス名とコメント以外はまったく同一である．また，S2 は apache commons ラ

タビューで回答している．また，2 つのソースコードから共通の親クラスを抽出するな

イブラリでの JUnit テストを実行するためのクラスで，参照するテストケースのクラス名

ど，一見して共通化することが可能と見えるほどに動作が似ているコードについては，だけが異なり，他は同一というソースコードの組である．Q6 や S2 は，クラス名自体がプ

参加者は集約方法を意識していた．

ログラム上重要であり，参加者は，それ以外のソースコード部分が似ていることにはあまりクラスの作成目的の一致． 本ワークショップで，全参加者が (b) あるいは (c)，つまり関連興味を示さなかったと考えられる．そもそもソースコード検索のデータベースに登録する価性があり，かつ両方を関連させたまま残すべきと判定したソースコードは，Q3 と R4

値がないコードであるという指摘もあった．

の 2 つであった．これらは，Prefix と Suffix，And と Or というように，一対となる

S6 は，public なフィールドばかりを持つ，C 言語でいう構造体に対応するような 2 つ

概念が 1 つの機能のために実装されたと推測することが容易なコードである．

のクラスである．クラスとして何とか抽象化できるのではないか，という意見がある一方クラスの役割． たとえソースコードが非常によく似ていても，参加者らは似ていること自で，まったく同じコードには見えないなど，参加者によって意見が異なっていた．

体に興味を示さなかったコードとして，例外処理のためのクラスや JUnit テストのク

3.2 類似性の判断基準

ラスが挙げられる．一部の参加者は，これらのコードを「自動生成されたようなコーセッション終了後，各グループに対して，ソースコードのどのような点に注目したか，口ド」と表現していた．

頭でのインタビューを実施した．また，参加者が注目した要素を推定するために，回答用紙

ファイルの新旧． グループ B，D は，コメントに記載された日付情報などからソースコーに記載された判断理由の中で頻繁に出現した単語を数え上げ，表 5 として整理した．ただドの派生関係を考慮しようとしていた．一方のバグが他方では修正されたと思えるようし，1 つのソースコードの判断理由に複数の単語が出現している場合もある．

なバージョンの差異では，古いほうを捨てるなど，集約とは異なる対応が必要であると

6

c 2009 Information Processing Society of JapanVol.2009-SE-166 No.20
2009/11/6

情報処理学会研究報告
IPSJ SIG Technical Report

いう指摘があった．このことから，単に似ているかどうかだけでなく，派生関係が重要

本ワークショップでは，作業コンテキストとして再利用データベースの構築を選んだ．検な意味を持つことがうかがえる．

索システムにおけるソースコード類似性のチェックという状況に限れば，同じように使える

参加者は，ソースコードの類似性を判断する基準として，識別子などの見た目だけでな部品が大事であるというように，作業コンテキストは結果に強く影響を与えていると考え

く，振舞いや役割の類似性やクラス階層での位置づけ，ファイルの派生関係といった幅広いられる．しかし，再利用といっても，部品をそのままブラックボックスとして再利用するの情報を用いていたことが判明した．この結果を踏まえると，類似したソースコードを調査すか，改変して再利用するのかで変わってくる，また，クラスの再利用かコード片の再利用るためのツールを開発する場合は，単に該当するソースコードそのものを提示するだけでなでも基準が変わった可能性がある，といった指摘があった．参加者の中には，再利用データ

く，ソースコードが置かれた状況を効果的に利用者に提示する機能が重要であると考えられベースにおける検索方法なども判断材料にしたいという意見もあり，作業コンテキストの設る．また，本ワークショップでは，ソースコード再利用というコンテキストに限ったにも関定は，厳密に達成されていたわけではない．

わらず，ソースコードの類似性の判断が参加者によって大きく異なるものとなった．ソース

5. 実施における反省点

コードの類似性判定に関する技術の適用実験を行う際には，その妥当性を注意深く検討する必要があるといえる．

本ワークショップは，著者らにとって初めての共同作業型のワークショップであった．本
節では，実施途中に気付いた点や，今後，類似した共同作業型ワークショップを開催する際

4. 妥当性への脅威に改善可能であると思われる点を整理する．

参加者募集にあたっては，過去に SIGSE ウィンターワークショップ「プログラム解析」

5.1 作業コンテキストの設定

グループへと参加したことのある研究者を中心に呼びかけを行ったため，ソフトウェア再利

作業コンテキストの提示方法に関しては，本ワークショップでは，ソースコードの「集約」

用，部品検索，リファクタリングなどの作業コンテキストに関しては十分な知識を持った参という用語が曖昧であり，Java 言語に固有の範囲であるのか，あるいはその他の方法を含加者が数多く含まれている．ただし，参加者の多くが教員および学生であることから，実務

むのか，参加者によって判断が分かれる結果となってしまった．

者の意見とは差がある可能性がある．

また，ソースコードを検索できるようにするという作業目的から，検索アルゴリズムに対参加者は，アンケートにおいて練習問題への回答理由を述べているが，判断基準を完全にする前提について，たとえば集約したときに差分データは検索対象となるか，検索時の索引は明文化していない．そのため，参加者が自分自身の判断基準を途中で変更している可能性に影響するのか，などの細かい条件に関する質問を行う参加者もあった．どこまで詳細化しがある．また，共同作業における議論には時間がかかり，参加者の疲労が大きかったと推測ておくかには議論があるが，本ワークショップでは，少なくとも「集約」という用語に対すされる．第 3 セッション，第 4 セッションでは，疲労した参加者による短絡的な判断が含る一貫した定義を用意しておらず，事前の検討が十分でなかったといえる．
作業状況の詳細を細かく詰めるほど，参加者にとっては判断の揺れが少なくなり，実験のまれる可能性がある．

再現性を向上できる可能性がある．一方で，事前に詳細な作業状況を作ることは難しく，予

ソースコードの提示方法として，ソースコードの組を対象とし，それ以外の情報，たとえ備実験の実施が重要となると思われる．

ばファイルの日付情報や，どのプロジェクトから取得したファイルであるかという情報は，参加者に提供しなかった．しかし，コメント中の日付に注目した参加者や，類似クラスが5.2 対象ソースコード

ただ 2 つだけなのかそれより多いかによっても判断が変わりうると指摘した参加者もあり，

本ワークショップでは，30 分〜45 分程度を 1 セッションと区切って 1 セッションあたり

6 組のソースコード，4 セッションを実施した．参加者が閲覧するべきソースコードの分量

ソースコードの提示方法は結果に影響していると考えられる．

が多く，第 2 セッションあたりでは議論が盛り上がっていたが，第 3 セッション，第 4 セッ

提示したソースコードは，ツールがある一定の類似性を持つと判定したソースコードのみであった．そのため，ソースコードの文面は似ていないが開発者が類似していると考えるよ

ションでは低調となっており，疲労の影響が出ていたと思われる．

うなソースコードが存在する可能性については調査を行っていない．

本ワークショップでは，ソースコードの提供方法として，行単位の差分と，行内の差分情7

c 2009 Information Processing Society of JapanVol.2009-SE-166 No.20
2009/11/6

情報処理学会研究報告
IPSJ SIG Technical Report

報を WinMerge によって可視化したものを印刷して提供した．しかし，行単位での diff

6. ま と めを基本として提示したため，インデントのみが異なるようなソースコード組に対して，それらが互いに大きく変更されているかのように可視化されてしまった例が 1 組存在した．参加

ソースコードの類似性ワークショップでは，18 名の参加者を 4 つのグループに分け，あ者の負担を下げるために，ソースコードの差異がたとえばパッケージ名，クラス名，メソッる 1 組のソースコードが類似していると考えるかどうか，という判断を手作業で行っていドの本文である，というように，注釈を追加するというやり方も考えられる．ただし，そのく共同作業を実施した．その結果，使用されている識別子の類似性やクラスが作成された目ような注釈によってソースコードを実際に目で見比べる時間が短くなり，実験結果に影響を的の類似性，派生関係などが判断に関係していることを確認した．
ワークショップで使用したデータ，分析結果等はすべてインターネット上で公開してい与える可能性もある．

る10) ので，自由に活用していただければ幸いである．

5.3 セッションの進行方法
セッションの時間進行については各グループに委ねたところ，予定時間を大きく超過する

謝辞 ワークショップにて共同作業にご参加いただきました 18 名の参加者に，深く感謝傾向があった．進行速度が最も安定していたグループは，アラームを用意して全員が同時にいたします．

1 つのソースコードを読み，判断を話し合うという方式を採用していた．

参

本ワークショップでは，残念ながら，議論の経過の様子を十分に記録することができな

考

文

献

1) Bellon, S., Koschke, R., Antoniol, G., Krinke, J. and Merlo, E.: Comparison and
Evaluation of Clone Detection Tools, IEEE Transactions on Softare Engineering,
Vol.33, No.9, pp.577–591 (2007).
2) CCFinder Oﬃcial Site: http://www.ccfinder.net/.
3) Kamiya, T., Kusumoto, S. and Inoue, K.: CCFinder: A Multi-Linguistic Tokenbased Code Clone Detection System for Large Scale Source Code, IEEE Transactions on Software Engineering, Vol.28, No.7, pp.654–670 (2002).
4) Roy, C.K. and Cordy, J.R.: Scenario-Based Comparison of Clone Detection Techniques, the 16th International Conference on Program Comprehension, Los Alamitos, CA, USA, IEEE Computer Society, pp.153–162 (2008).
5) WinMerge: http://winmerge.org/.
6) 澤 健一，肥後芳樹，楠本真二：コードクローン検出ツールを用いた不具合検出手法の提案と評価，電子情報通信学会技術研究報告， Vol.108, No.173, pp.67–72 (2008).
7) 吉田則裕，肥後芳樹，神谷年洋，楠本真二，井上克郎：コードクローン間の依存関係に基づくリファクタリング支援，情報処理学会論文誌， Vol.48, No.3, pp.1431–1442(2007).
8) 渡邉卓也，増原英彦：類似プログラムの提示ツール Selene，日本ソフトウェア科学会
第 24 回大会 講演論文集，3B-2，pp.1–9 (2007).
9) 佐々木裕介：利用関係に基づく類似度を用いた Java コンポーネント分類ツールの作成，
大阪大学 卒業論文, http://sel.ist.osaka-u.ac.jp/∼lab-db/Bthesis/contents.
ja/121.html (2009).
10) 石 尾 隆 ，山 本 哲 男：ソ フ ト ウェア の 類 似 性 ワ ー ク ショップ，http://sel.ist.
osaka-u.ac.jp/JWSCS2009/.

かった．回答用紙のみからでは，各個人の判断は記載されているが，断片的な単語のみが記載されていることもあり，たとえば，誰の意見に影響されたのか，合意が生じたのか，ある
いは偶然判断が一致しただけなのか，といった詳しい状況を知ることができなかった．各グ
ループでの議論を記録する（発言は行わない）書記が 1 名ずつ加わることが効果的であると考えられる．また，本ワークショップでは，事後アンケートを口頭で実施したが，全員からの意見を十分に収集できなかった可能性がある．各個人で，ソースコードのどの部分に注目したかなど，より詳細な情報をアンケートに記載してもらうことが情報収集として効果的であった可能性がある．
今回，ソースコードと回答用紙を紙で用意したところ，ソースコード 4 部を印刷したもの
が A4 用紙で 456 枚，回答用紙が A4 で約 400 枚必要となった．著者らはすべての資料を会場まで持参したが，ソースコードの量や印刷方法などによっては，ローカルアレンジ担当者との連携による郵送などの手段が必要になる可能性がある．
最後に，当日参加や，やむを得ない事由により途中参加となってしまった参加者への対応が必要であった．簡単な対策としては，当日参加者を 1 つのグループにまとめる方法がある
が，配布資料の印刷部数などに影響することから，既存グループに吸収する形とした．当日参加者には，口頭で開発経験など自己紹介を行ってもらったが，十分な情報を漏れなく獲得するために，参加者と同様のアンケートを記入してもらうべきであった．なお，SIGSE
ウィンターワークショップのように当日参加を禁止した形式での実施であれば，参加者のグ
ループ分けや配布資料の印刷等，事前準備の負担が大きく削減されると考えられる．

8c 2009 Information Processing Society of Japan