外部から見た振る舞いとアクセス手段に注目したソースコード類似性
佐々木裕介 †石 尾隆†

山 本 哲 男 ††本稿ではソースコード類似性に関するアンケートを作成する上で，どのような意図で設問を用意したかについて言及している．我々は再利用促進を目的としたソフトウェア部品検索システムの研究を行っており，再利用という観点でソースコード類似性を判断する際には，外部から見たときのアクセス手段と振る舞いに注目している．

1. は じ め に似であるとみなしている．1 つにまとめるのが容易であるとは即ち，共通する記述を抽出したときに外部か開発者のソフトウェア部品の再利用を促進するためら見た振る舞いが変わることなく，かつ 2 者の実装方に，ソフトウェア部品検索システムが研究されてい法（import しているクラスも含む）も類似している場

る1) ．検索対象となるソフトウェア部品の収集時には，合を指す．ただし定数や引数の型など一部のパラメー

プロジェクト間で複製され再利用されたもの，同一部タのみ異なるものについては，テンプレートをスー品の異なるバージョンなども蓄積されていく．このた

パークラスとして作成することで 1 つのクラスへまとめ，検索結果の上位をそのような類似部品群が占めてめることが可能と考え，類似とみなしている．

しまい，利用者が部品を探す作業の効率が悪化するこ観点

B

同じ構成の記述が多いほど同じバグを含んでいる可とがある．
そこで我々は，ソフトウェア部品検索システムにお能性が高いと考え，類似とみなすことにした．同じ構

いてこの冗長性を解消するために，再利用性の観点か成の記述が多いとは即ち，差分として認識できるトーら類似コードをグループ化して表示するための研究をクン数が全体のトークン数と比べて少ないことを指す．

行っている．類似判断の基準としては，あるコードと観点

C同じグループに属する別のコードを入れ替えたとき，置き換えが可能であるためには，外部から見た振る同じように利用可能であることを類似条件としている．

舞いと，外部からのアクセス手段が同じでなければな

また今後の展望として，単なる再利用以外の用途，例らないと考え，これら 2 つを基準とした．振る舞いにえば 1 つのコードにまとめることが可能なコード群のついてはパフォーマンスの違いは考慮せず，メソッド管理，管理しているコードのバグ検出などにもソフトの実行が終わったときに外部から見たときのクラスのウェア部品検索の技術を応用できないかと考えている状態が同じであれば類似と判断する．

ため，アンケートでも様々な観点から考察した回答を観求めている．

観点 D については，具体的なシナリオとして類似

2. アンケート回答

点

D

性を用途別に分類して管理することを想定し，他の観点 A-C において一つでも類似であると判断されてい第一著者の回答の結果は表 1 のようになった．各観る場合は類似とみなしている．例えばクラス X,Y が点において何を基準にして類似・非類似を判断したか

観点 A において類似とみなされていれば，X,Y が類は以下に記述する．

似であることと観点 A において類似判断したこと両観点A

1 つにまとめるのが容易であるコード片の組のみ類† 大阪大学
Osaka University†† 立命館大学
Ritsumeikan University方を記録する．

3. 各設問の意図
3.1 ソース No.1 について
クラス名が異なると外部からアクセスされるときのプロトコルも変わるため，クラス名のみ異なるコード

表1

る理由の一つとして，外部オブジェクトが states へ代

設問への回答ソース No.

ABCDX入できるオブジェクトの範囲が異なることが挙げられ

1
2
3
4
5
6
7
8
9
10
11

yes
no
no
no
no
no
yes
no
yes
yes
no

yes
yes
yes
yes
yes
yes
yes
no
yes
yes
no

yes
no
no
no
yes
no
yes
yes
no
yes
no

yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
no-る．またコードを単なるトークンの系列とみなしたとき，異なるトークンの数自体は少量とみなせるが，全体として異なる割合，つまり (差分トークン数) / (総トークン数) は比較的大きい数値になる．

3.7 ソース No.7 について処理の抽出のように，クラスの振る舞いを変えない
簡単なリファクタリングであっても，コードをトークン系列とみなして違いを定量的に計算する場合には，この差が大きな違いとして検出される可能性がある．

3.8 ソース No.8 について片の組を取り上げた．ただし名前の違いは極めて表面

コードの記述方法やパフォーマンスに注目して類似的なものであり，クラス自体の振る舞いには影響を与判定を行う場合には，アルゴリズムの違いは大きな差えない．と考えられる．一方でコードの実行結果や振る舞いに

3.2 ソース No.2 について注目する場合には，アルゴリズムの違いは類似判定に提示したコード片の組は，メソッド changeIndent

大した影響を与えない．のアクセス修飾子以外は同じである．しかしアクセス

3.9 ソース No.9 について修飾子の異なるメソッドを単純に 1 つにまとめると，提示したコード片のように，記述の違いが型とメ外部からアクセスする場合のクラスの振る舞いが元のソッド及びフィールドのパラメータのみであっても，ものと別のものに変わってしまうので，回答者の観点クラスの機能が全く異なるケースが存在する．

によって意見が分かれると考えられる．

3.3 ソース No.3 について

3.10 ソース No.10 について
No.10 はコードをトークン系列とみなしたとき，差インタフェースでは具体的な実装はほとんど行って分として検出されるトークンの割合はトークン総数といない．しかし，引数の型の間違いなどはクラスと同比較すると少ないが，トークンの数そのもの（絶対数）様起こりうる．また，インタフェースの定義が異なるが多い例である．と外部からアクセスする方法も異なるため，回答者によっては意見が異なると考えられる．

3.11 ソース No.11 について
No.11 はコードをトークン系列とみなしたとき，差3.4 ソース No.4 について分として検出されるトークンの割合はトークン総数と提示した例では，IPv4 を処理するコードの代わり比較すると多いが，トークンの数そのもの（絶対数）に IPv6 を処理するコードを用いることは可能だが，が少ない例である．

その逆は不可能である．よって観点 C からこれらのトークンの差分を用いて類似判定を行う際には，コード片の類似性を考察する場合，類似であるとみなNo.10 のようなケースと No.11 のようなケース両方すかどうかは類似の判断結果を利用する状況に依存すを考慮する必要がある．

る．例えばグループ化により類似コードを分類する際に，No.4 のコード片の組を同じグループに含めた場
合，そのグループ内のコードは必ずしも置き換え可能ではないということになる．

3.5 ソース No.5 について外部から見たときに最終的に果たされる役割が同じであるという点では，2 者の入れ替えは可能であると考えられる．しかし利用しているライブラリの実装の差異のため，性能は異なったものになる．

3.6 ソース No.6 について
No.6 のコード片の違いはフィールド states のインタフェースが異なることである．そのため非類似とす

4. 謝

辞

本研究は，日本学術振興会科学研究費補助金基盤研
究（A）（課題番号:21240002）の助成を得た．

参考文献1) 横森 励士, 梅森 文彰, 西 秀雄, 山本 哲男, 松下誠, 楠本 真二, 井上 克郎.: Java ソフトウェア
部品検索システム SPARS-J , 電子情報通信学会論文誌 D-I, VolJ87-D-I, No.12, pp1060-1068,
2004.