プログラマはどのように低水準なデータ型を使って高水準の概念を表現しているのか?

0. 概要

• 現代のプログラミング言語はさまざまな型をユーザが定義可能である。
• いっぽう String 型と int 型は「一般的な型」であり、 さまざまな用途に使われている。
• プログラマは、ふさわしい変数名によってこれらの型の「目的」を区別していると考えられる。
• 明らかに意味的に定まっている以下の「型」がどのような式で表現されているかを調査した:
  • String型: パス名, URL, ホスト名, SQL文
  • int: ポート番号, (GUI上の)X座標,Y座標,幅,高さ, 年, 月, 日
• 測定手法: Javaの標準APIには、上記の値を (Stringあるいはintの) 引数としてとるメソッドが多くある。 プログラマはあきらかにその引数の用途を理解しているはずなので、これらの式を調べる。
• 実験方法:
  1. 26個の有名なオープンソースプロジェクト (大規模) を選ぶ。
  2. こちらで選択した 110個の Java APIの呼び出し引数 (218項目) を列挙する。
  3. これらに使われている識別子の統計をとる。
  4. これらの識別子のデータフローから「型 (c-type)」を推論できるかどうか実験する。
• (ほぼ自明な)結論: 多くのプログラムで、パス名には path、座標には x, y などの識別子が使われていることがわかった。
• データフローを決定木で解析することにより、これらのうち 83% (F値) を正しく識別することが可能。

1. 背景

よく「悪いコード」として primitive obsession と呼ばれる現象がある:

String username = getCurrentUserName();
String path = "/home/"+username+"/user.cfg";
// Unsafe path: extra check is needed!
File config = new File(path);

まともな (しかし面倒くさい) コード:

User user = getCurrentUser();
Path path = Paths.get(user.getHomeDirectory(), "user.cfg");
// Path is guaranteed to be safe.
File config = new File(path);

Primitive obsession はリスキーだが多くのプログラマが使っている。

1.1. Research Questions

1. 多くのプログラマが使う「高水準な型 (abstract type, or Conceptual Type, c-type)」とはどんなものか?
2. プログラマはそのような概念をコード中でどのように表現しているか?
3. コードからそれを推論することは可能なのか?

1.2. Related Work

• O'Callahan et al.: 静的解析 + 型推論による型の判別。同じ位置に格納されれば同じ型とみなす。
• Guo et al.: 動的解析 + 型推論。
• Dash et al.: 似た名前であれば似た型。
• Jiang et al.: 次元解析 (dimensional analysis) による型の不一致検出。

2. 基本的なアイデア

プログラマは APIを呼び出すとき、その引数の用途 (c-type) を知っているはず:

String x = "foo/bar.txt";
var f = new java.io.File(x);  // x はパス名

いくつかの Java オープンソースプロジェクトを調査し、 以下の 12 の c-type を定めることにした:

これを選んだ基準は以下のとおりである:

1. ほとんどのプログラマが理解できる明確な概念であること
2. 互いにきっちり区別できること
3. 広範囲のアプリケーションで使われていること

つぎに Java Standard API を調べて、 これらの c-type を含む計218メソッド (重複あり) を列挙した:

• new java.io.File(PATH)
• new java.net.URI(URL)
• java.sql.Statement.execute(SQL)
• java.net.InetAddress.getByName(HOST)
• new java.net.Socket(HOST, PORT)
• new java.awt.Point(XCOORD, YCOORD)
• new java.awt.Dimension(WIDTH, HEIGHT)
• new java.util.Date(YEAR, MONTH, DAY)
• java.util.Date.setYear(YEAR)
• java.time.LocalDate.of(YEAR, MONTH, DAY)
• ...

3. 実験

実験は以下の手順でおこなった:

1. 中〜大規模の 25 のJava オープンソースプロジェクトを選ぶ。
2. ソースコードを解析し、あらかじめ選んだ API 呼び出しを探す。
3. それらの引数で使われている式を収集し、 その種別・大きさ・識別子に使われている単語などを調べる。

例

zookeeper/.../TxnLogToolkit.java:

    File file = new File(dir.getPath() + File.separator + Util.makeLogName(zxid)[PATH]);
    ...

jitsi/.../SIPCommSplitPaneDivider.java:

    rightButton.setBounds((insets.left * 2) + leftSize.width + rightSize.width[XCOORD],
                          y[YCOORD], rightSize.width[WIDTH], rightSize.height[HEIGHT]);

使用したプロジェクトとLoCは以下の通りである:

各プロジェクト・c-typeごとの抽出された式の数は以下のとおりである。 出現する式の数は、プロジェクトの大きさにほぼ比例する。 しかし c-typeの種類はプロジェクトによって偏っている。

以下は抽出した式に含まれていた PATH, URL, XCOORD, WIDTH 表現の抜粋である:

各c-typeにおける、複雑な式と演算子の組合せ例は以下のとおりである:

mLocalUfsPath + ufsBase
selectedFile.getAbsolutePath() + PREFERENCES_FILE_EXTENSION
dir.getPath() + DIR_FAILURE_SUFFIX
U.defaultWorkDirectory() + separatorChar + DEFAULT_TARGET_FOLDER + separatorChar

url.toExternalForm().substring(GhidraURL.PROTOCOL.length() + 1)
str + KMSRESTConstants.SERVICE_VERSION + "/"
newOrigin(getScheme(),getHost(),getPort()).asString() + path
base + configFile

center.x + center.width
leftButtonWidth + leftWidth
evt.getX() - getInsets().left
prefs.getInt(name+".x", 0)

Math.max(contentWidth, menuWidth) + insets.left + insets.right
TITLE_X_OFFSET + titlePreferredSize.width
width + insets.left + insets.right + 2
(int)(bounds.getWidth() * percent)

抽出した式の長さは以下のとおりである (nは式中の項の数を表す):

4. C-type の推論

次に、式の表現のみから c-type を推論できるかどうかを考えてみる。 今のところ、我々は c-type の判定は API 呼び出しに頼っている。 もしこれができれば API呼び出し以外の部分の c-type も判定することができる。

基本的な戦略は以下のとおりである:

1. 抽出した c-type とその式 (12k) を訓練データ・テストデータとして使用する。
2. 各式から分類に使えそうな特徴量を抽出する。
3. 機械学習 (決定木) を使って、どれくらいうまく判定できるかを測定する。

機械学習アルゴリズムとして決定木を使ったのは、 記号的な特徴に向いており、かつ、できあがった規則が人間に読みやすいためである。

まず、式に出てきた識別子のうち、頻出の単語を取り出すと 以下のようになる:

本手法では、式の特徴を表現するのにデータフロー図を使った。 式を構文解析して項どうしの依存関係を抽出する。 たとえば new File(config.getPath(i)) のデータフロー図は 以下のようになる:

各式に対して、データフローから "primary identifier" および "secondary identifier(s)" を 特徴量として使用して学習する。 以下のような規則を使うと、以下の素性が抽出できる:

• Primary identifer: getPath()
• Secondary identifiers: config, i

これらの素性を使って、各ctypeを判別可能かどうか実験した。 ここでは評価にプロジェクトごとの leave-one-project-out の クロスバリデーションを使っている:

• プロジェクトをひとつ選び、そこに表れる式 (およびその ctype) をテストセットとする。
• 残りのプロジェクト 25個の式を訓練セットとする。

以下のような結果が得られた:

URL c-type は性能が悪い。 その理由は、URLの式は

"https://"+getHostName()+":"+getPort()+"/"+getPath()

5. 結論

本研究では、Java standard API で使われている 12 の c-type を定義し、 それらが 26個のオープンソースプロジェクトでどのように使われているかを分析した。 ソースコード中の API 呼び出しを収集してそれらの傾向を調べた。 その後、データフロー解析と決定木を組み合わせた c-type 判定手法をテストした。

Research Question ふたたび:

1. 多くのプログラマが使う「高水準な型 (abstract type, or Conceptual Type, c-type)」とはどんなものか?
   → 12個のc-typeを定義した。実験によれば、それらの出現頻度はプロジェクトのドメインに依存していた。
2. プログラマはそのような概念をコード中でどのように表現しているか?
3. コードからそれを推論することは可能なのか?
   → これらの質問は関連している。比較的単純な決定木ベースの手法が うまくいっているので、少なくともよく知られているコンセプトに対しては、 プログラマは c-type を判定しやすいように書いていると思われる。

5.1. Threats to Validity

• 使ったAPI以外にも c-typeの表れる可能性がある。
• オープンソースを使ったことによる選択バイアス。
• いくつかの c-type はめったに使われない。
• いくつかの c-type は曖昧にしか定義できない: たとえば URL と URI、ファイル名とパス名など。
• 「定義されていない c-type」をどのように扱っていいのかわからない。 この実験では、一部の引数を "OTHER" タイプとして判定したが、 潜在的にはこのような引数は非常に多い (あるいはほとんど) かもしれず、 それを含めれば判定精度はずっと下がる可能性がある。