データフローグラフ FGyama と
ソフトウェア情報抽出の見通し

新山祐介
権藤研輪講 2018/10/16

そもそものモチベーション

「知性とは何か?」
- 「ゲーデル・エッシャー・バッハ」に感化される。
- 認知科学・自然言語処理に興味。
  - 空間的位置関係の言語による表現
    (徳永研、1998年)
  - ニュース記事のマイニング
    (NYU、2006年)
- 失望: 自然言語処理 = ほぼ文字列処理だった。

モチベーションつづき

まず「意味とは何か?」を考える必要がある。
- そもそも言語の意味に関する理論は不十分。
  - 自然言語処理では「意味」という単語はタブー。
  - 意味 = 重みづけベクトル。(word2vec)
    - リンゴ = 赤 + 甘い + 果物 + ...
    - お金 = ???
- 単語 → 実体に関連づける枠組み (grounding) がない。

モチベーションつづき

前段階として「ソフトウェアの意味」ならもう少し厳密に定義できるのでは?
- ソフトウェアは社会のあらゆる概念を処理するのに使われている。(リンゴ、お金、etc.)
- 概念は仕様書ですべて定義されている (はず)。
- 実際には、曖昧な概念が多い。
  - C/C++/Java における「ストリーム」
  - Java/C++ における「クラス」
  - git の「commit」

背景知識

大目標: 「ソフトウェアの意味を表現・分析できるような枠組み・ツールを開発する」
- 問題の簡略化: 入力 → 処理 → 出力
- ソフトウェアの意味 = (数学的な) 入力-出力の関連に着目。
- 「プログラムのデータフロー」 ≅ 「プログラムの意味」と仮定。

研究の目標

プログラムの意味を表現・分析に使えるデータフロー形式を提案し、その変換・処理ツールを開発する。
- 特定のプログラミング言語に依存しないこと。
- なるべく汎用的な目的に使えること。
- 現実的な資源で処理できること。
「開発ツール」「検査ツール」は飽きた。

大規模なコードベースを理解することが深刻な問題。 (職業プログラマの勘)

研究のプロセス

データフローグラフ FGyama を考案する。
- よさそうなのができるまで試行錯誤する。
とりあえずJavaからの変換器を実装する。
FGyama を使うことで、ソフトウェアの意味に関する興味深い特性が抽出可能であることを示す。
- なにが興味深いのか?

各学年における「研究」

学部における「研究」… やればできる。やるだけ。
修士における「研究」… ガンバればできそう。
博士における「研究」… できるかどうか謎。

argmax (新規性 × 有用性)

新規性の追求 = プログラム意味解析に役立つ新たな方法論を提案できれば面白いだろう。
有用性の追求 = 大規模ソフトウェアの解析・理解に貢献することがもっとも切実である。
目標 = 大規模ソフトウェアの "big picture" を提供できる手法をあみだす。

FGyama の特徴

ソースコード解析である。
- プログラマの「意図」を抽出したい。
```
int seconds = 60;
int minutes = 60;
int hours = 24;
int limit = seconds * minutes * horus;
timeleft = limit;
```
  vs.
```
mov $86400, %eax
```
- コードの一部でも解析可能。
Interproceduralである。
- 大局的な意味解析に使いたい。

FGyama の利用可能性

基本的な手法は「データフローグラフの比較」である。
関数・メソッドの相関検出:
「その関数の使われ方が類似していれば、それらは関連する機能をもつだろう」 (… ホントかっ。)
```
int add(int a, int b);
int sub(int c, int d);
```

メンバ変数の相関検出。

struct mark {
  int x;
  int y;
  int color;  // 明らかに別用途。
};

変数の「属性」を発見する:
(taint解析に近い)
1. 「ループの終了判定に使われる」
2. 「処理のセレクタとして使われる」
3. 「ネットワークに送られる運命にある」

Leaky abstractionの判定?

basedir = "/home";
path = basedir+"/"+username; // leaky
data = open(path).read();

Nullable/const/enum型の検出。

既存研究との関連

既存のデータフロー解析 (例: FlowDroid) はおもに「2点間のフローが存在するか」を検査するものである。
一方、本手法ではフローの存在よりもデータ間の「関連」を重視する。
データフロー「グラフ」をここまで真剣に考慮している研究は存在しない。

今後の計画

データフロー表現のための一般的な形式 FGyama を設計する (済)。
(Java, 6kloc, 実装の苦労話)
Javaソースコード → FGyama 変換ツールを実装する (ほぼ済)。
GitHubからのデータ収集 (済)。
素性を抽出し、興味深い結果をみつける。
国際会議で発表後、論文誌に投稿予定。