一枚だけで概要説明

RQ: コードの意味は、その処理自体だけでなく利用方法によっても規定されるのではないか?
様々なメソッド呼び出しにおける周辺のデータパスを取得・解析してみよう。
あるメソッドから出る2つのパスが類似していれば、それらのメソッドは意味的に類似しているのでは? (機能的クローン)

機能的クローンとは何か?

機能的クローン = (ほぼ) 等価な機能をもつ異なるコード。

int max(x, y)
{
    return (x < y)? y : x;
}

int max(x, y)
{
   if (x < y) {
      x = y;
   }
   return x;
}

比喩による例 (1)

問. つぎの資格を埋めなさい。

「おにぎりを買いにコンビニへ出かけた」
「洗剤　　を買いにコンビニへ出かけた」

比喩による例 (2)

問. つぎの資格を埋めなさい。

「腹がへったのでおにぎりを買いにコンビニへ出かけた」
「腹がへったのでラーメンを買いにコンビニへ出かけた」

比喩による例 (3)

問. つぎの資格を埋めなさい。

「腹がへったので赤いきつねを買いにコンビニへ出かけたが、ポットのお湯がなかった」
「腹がへったのでどん兵衛　を買いにコンビニへ出かけたが、ポットのお湯がなかった」

観察: 文脈が長くなるほど、単語の意味は類似してくる。

比喩による例 (4)

「売れ残った大量の zxmqtg を家畜のエサにした」
「売れ残った大量の pfkrjw を家畜のエサにした」

単語が何を指しているかは不明でも、似たようなものだろうということは推測できる。

基本的なアイデア

RQ: あるメソッド呼び出しの使われ方 (=文脈) が類似していれば、そのメソッドは類似した機能 (=意味) をもっているのではないか?
- Let's find out!

メソッドの使われ方 = データパス

ここでは、あるメソッドの返り値が通る一連の処理を、そのメソッドの「使われ方」と定義する。
「データフロー解析」というと既存の手法と誤解されそうなので、データパスという単語を用いた。

データパスの例

問. 以下の例で fp.readLine() の返り値は 2回利用される。どのように利用されているか?

private BufferedReader fp;

public String get() {
    String s = null;
    s = fp.readLine();
    int i = s.indexOf(' ');
    return s.substring(0, i);
}

グラフ化するとこうなる:

グラフ中の readLine() からたどったノードをデータパスとする:
- readLine() - #this:indexOf() - #arg1:substring() - return
- readLine() - #this:substring() - return
これは readLine() の返り値がどのように使われたかを示している。

Interprocedural 化する

private BufferedReader fp;

public String get() {
    String s = null;
    s = fp.readLine();
    int i = s.indexOf(' ');
    return s.substring(0, i);
}

void show() {
    String x = get();
    System.out.println(x+"!!");
}

グラフ化するとこうなる:

ここから得られる readLine() のデータパスは:
- readLine() - #this:indexOf() - #arg1:substring() - L:+ - #arg0:println()
- readLine() - #this:substring() - L:+ - #arg0:println()
以上2つの順列が、このプログラムにおける「readLine()の使い方」ということになる。
- 単純化のため、いまのところメソッドの返り値のみを使う。
- グラフ上の分岐は考慮せず、一本のパスのみを扱う。

データパスを収集する

フローグラフ抽出器 FGyama を利用する。
Java ソースコードから前出のようなグラフを生成する。
- 問. 上のグラフで...
  1. Flow sensitivity が必要な箇所はどこか。
  2. Context sensitivity が必要な箇所はどこか。
  3. Field sensitivity が必要な箇所はどこか。
グラフをデータパスに変換する。

ソースコード解析のいいところ

なるべくプログラマの意図を残しておける。
コンパイルの過程で消される部分も使える:
- コメント
- 最適化でなくなる変数:
```
const int a = 3;
int b = a + 1;
```
バイナリでは同一になる部分も区別できる:
- Java の type erasure による同一化:
  - List<Integer>.add()
  - List<String>.add()
- Calling context によってメソッドの区別, etc.

メソッドをクラスタリングする

各メソッドのデータパスをその「素性」とする。
同じ素性をもつメソッドをグループ化。
素性の順列の現れる確率に応じてランキング。
P = p₀(s₀) × p₁(s₁) × ... × p_n(s_n)
(確率が低いものが一致するほどよい)

評価実験

RQ: あるメソッド呼び出しの使われ方 (=文脈) が類似していれば、そのメソッドは類似した機能 (=意味) をもっているのではないか?
評価方法: データパスによってクラスタリングしたメソッドが、実際に機能的に類似しているかどうかを検査する。
実際の評価は人手で作成したデータをもとに行う:
- 100件程度のメソッドを目で見てグループ化する。
- 権藤先生と荒堀さんにもオネガイする。

機能的クローンの評価基準

2つのメソッド A, B に対して:
1. A と B が完全に同じ。
2. 条件分岐によって A または B が使われる。
```
x = (c)? A() : B();
```
3. 一方が他方を継承したメソッドである。
4. 一方の機能を使って、他方の機能を実現可能。
5. 一方と他方の機能が正反対 (相補的) である。
6. 同じ型を対象とした処理である。

比較実験 (予定)

別の手法によって機能的クローンを発見し、精度を比較する:
1. メソッド名による比較。
  (似た名前であれば機能的に似てるだろう)
2. メソッドのコード自身による比較。
  (似たコードであれば機能的に似てるだろう)
  [トークン + ベクトル類似度]
(期待する) 本手法の有利な点:
1. 名前がまったく違っていても比較できる。
2. そのメソッド自身のコードは存在しなくても比較できる。
3. データパスの強度によって、類似度のようなものを計算可能。

実験対象

以下のソースコードからデータパスを抽出した:

プロジェクト	SLOC	メソッド	ノード
xz-1.8	6,864	747	54,170
jhotdraw-5.3	14,611	2,269	66,508
antlr4-4.7.2	31,122	2,206	78,362
jedit-5.3.2	116,416	-	-
tomcat-8.5.33	235,009	21,954	1,443,730

このほかの予定検体: ant, junit, weka, javaassist, pmd

これまでの結果

ひとつのプロジェクト内での機能的クローン:
そこそこよい: xz, tomcat, jhotdraw.
異なるプロジェクト間での機能的クローン:
ぜんぜんダメ: 3種混合.

結果が悪い原因

そもそもクローンが存在しないのでは?
抽出プログラムにバグがあるのでは? (大アリ)
一本のデータパスだけを素性として考慮するのでは弱い (複数のデータパスだけを同時に考慮する必要がある) かもしれない。
- データパスを階層的にマッチングさせる手もある。

将来の計画

現在はメソッドのデータパスだけだが、フィールドのデータパスも収集し比較する:
- → 「似たような意味をもつ異なるフィールド」を発見できるようにする。
データパスは逆方向にたどることもできる。メソッドへの入力 (引数) をたどっていくと、何がわかるのか?

すぐやること

論文誌に投稿する:
IEICE CFP, 8ページ (2019/2/28 JST 締め切り)
FGyama のバグ修正。
比較手法 (名前、トークン) の実装。
評価システムの構築および評価。
- 定量的な評価基準の構築。(おそらく Fleiss' Kappa)