社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

メトリクス計測や解析のためのソースコード平坦化
肥後芳樹†

楠本 真二†† 大阪大学 大学院情報科学研究科 コンピュータサイエンス専攻 〒 565-0871 大阪府吹田市山田丘 1-5
E-mail: †{higo,kusumoto}@ist.osaka-u.ac.jp
あらましソースコードに対してメトリクスの計測や解析を行う場合には，その前処理として正規化が行われることが多い．正規化を行うことよりソースコード中から処理の対象ではない要素が取り除かれたり，ソースコード中の要素が整形されたりするため，より有意な処理結果が得られる．既存の正規化は，プログラムの振る舞いに影響を与えないコメントや空白行の削除や整形，もしくは変数名やリテラルを一定のルールに従って他の名前に置換するというプログラムの字句が対象のものがほとんどである．本研究では，複雑なプログラム文や条件式を平易なプログラム要素へと変換する正規化を提案する．本研究ではこの正規化を平坦化と呼ぶ．平坦化によって，平易なプログラム要素と複雑なプログラム要素が入り混じったソースコードは，平易なプログラム要素からのみ構成されるソースコードへと変換される．本稿では平坦化の効果を調査するために，平坦化前後のソースコードに対する行数メトリクスの計測結果およびコードクローンの検出結果についても報告する．
キーワード ソースコード解析，メトリクス計測，ソースコードの正規化

1. は じ め に似ているファイルや関数・メソッド，コード片の検出 [19] や関
数やメソッドの呼び出しパターンの検出が挙げられる．

ソフトウェアのソースコードはソフトウェア工学における主

メトリクスの計測や頻出コードパターンの検出では，より良要な研究対象の 1 つであり，さまざまな目的のためにソース

い結果を得るために，計測処理や頻出コードパターンの検出処

コードを対象とした研究が行われている．

理に先立ってソースコードの正規化が行われることが多い．こ•ソースコードの解析を行う目的の 1 つとして，現状のこでの正規化とは，ある一定の規則に従ってソースコードを変ソースコードの把握が挙げられる．ソースコードの規模や複雑換する処理のことである．例えば，メトリクスの計測において度，その構造に関するデータを定量化して開発者に提示するこは，ソースファイル内のコメントを削除やフォーマットを統一とでソースコードの状態をより客観的に把握できる [8]．また，といった正規化が行われる．頻出コードパターンの検出では，

関数・メソッドの呼び出し関係やオブジェクト指向言語におけ変数名やリテラルを特殊な文字に置換した上で検出の処理が行るクラスの継承関係等，ソフトウェアを構成するモジュール間

われる場合が多い．このように，既存の正規化方法はプログラの依存関係を可視化する研究も行われている [13], [22]．

ムの振る舞いに影響を与えない空白行やコメントに関するもの•

既存のソフトウェア資産を効果的および効率的に再利用やプログラムの字句に対して行われるものが多い．

することを目的とした研究においてもソースコードは解析対象

本研究では，ソースコードの構造を正規化する手法を提案すである．頻繁に再利用されるソースコード部品やソースコード

る．提案手法により，ソースコード内に存在している複雑なプ中に頻発するコードのパターンの特定 [1] やコーディング中にログラム文や条件式は複数の簡単なプログラム要素に分解されその場所で利用可能な関数・メソッド等の補完を行う研究が行る．つまり，複雑なプログラム文と平易なプログラム文が入りわれている [20]．

混じったソースコードは平易なプログラム文のみで構成される•

ソフトウェアの問題点を発見したり改善案を提示したり

ソースコードに変換される．本研究ではこの正規化を平坦化とする研究も広く行われている．問題点を発見する研究として呼ぶ．平坦化により，ソースコード一行当たりのプログラムのはフォールトプローンモジュールや脆弱性を含むコードの特機能が均一化されるため，行数等のメトリクスがより有意な値

定 [5], [15]，改善案を提示する研究としてはリファクタリングになることが期待される．また，構造が正規化されることによを行うべきコードの特定 [17] が挙げられる．

り，より多くの振る舞いが同一なコードが頻出コードパターン

それらの研究において広く利用されている技術としてメトとして検出されることが期待される．

リクスの計測や頻出コードパターンの検出が挙げられる．モ

本稿では，ソースコードの平坦化手法の提案に加えて，平坦

ジュールの行数，循環的複雑度，CK メトリクス等がよく利用さ化したコードに対する行数メトリクスの計測と，コードクロー

れるメトリクスである．頻出コードパターンの検出としては，—1—

ン検出の適用結果についても述べる．行数メトリクスの計測では，平坦化により大きく行数が増えるソースファイルが多数あることが確認された．また，ファイルの行数メトリクスとそのファイルに存在しているバグの有無の相関を調査したところ，提案手法を適用することにより，多くの場合において相関が高くなることが確認された．コードクローン検出については，提案手法を適用することでより多くのコードクローンが検出されるようになることが確認された．

2. 関 連 研 究
ソースコードの正規化はコードクローンの検出手法でよく利用される [3], [7], [10]〜[12], [18], [21] ．コードクローン検出ではソースコードの正規化は変数名を特殊文字に置換することが多い．全ての変数を同一の特殊文字に置換する方法と，異なる
変数名を異なる特殊文字に置換する方法がある．後者は変数名

…
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
…

public int read() throws IOException {if (needAddSeparator) {if (lastPos >= eolString.length()) {lastPos = 0;
needAddSeparator = false;} else {return eolString.charAt(lastPos++);}}while (getReader() != null) {int ch = getReader().read();if (ch == -1) {nextReader();
if (isFixLastLine() && isMissingEndOfLine()) {needAddSeparator = true;
lastPos = 1;
return eolString.charAt(0);}} else {addLastChar((char) ch);return ch;}}
return -1;}の対応付けが保たれているので，前者の正規化に比べて誤検出
図 1 複雑なプログラム文を持つソースコードが少ない．
ソースコードの解析を支援する方法として，ソースコードを解析しやすい別の形式に変換するという研究も行われている．

Cordy は TXL というソースコードを変換するためのフレームワークを提案している [6]．Maletic らは XML でソースコードを表現するフレームワーク srcML を提案している [16]．ソース
コードを XML で表現することで，XML を操作するさまざまな既存ツールを利用することでソースコードを操作できる．
ソースコードの構造を変更する手法としては，ソースコード
中から goto 文を取り除き振る舞いが等価なプログラムを生成

…
284
285
286
287
288
289
…
295
296
297
298
299
300
301
…

needAddSeparator = false;} else {int $24 = lastPos++;char $25 = eolString.charAt($24);
return $25;}
if (ch == -1) {nextReader();boolean $28 = isFixLastLine();boolean $29 = isMissingEndOfLine();if ($28 && $29) {needAddSeparator = true;
lastPos = 1;する手法が提案されている [2], [23]．これらの手法には変換の際に制御依存グラフを利用する．制御依存グラフの形状が変わ

図 2 図 1 のソースコードを提案手法により平坦化した後の状態

らないソースコードが出力される．
ソースコードに対して自然言語処理の手法を適用する際にに多いかを知ることは難しい．また，50 行と 100 行という情報

は，ユーザ定義名の正規化（変数名等を英単語に分割）が行わだけでは，後者の方をよりフォールトプローンであると判定しれる [14]．また，マルウェアを検出するためのアセンブリコーてしまうだろう．

ドの正規化方法も提案されている [4]．

3. 研究の動機

ソースコード解析の例としてコードクローンの検出を挙げる．検出されたコードクローンは，類似バグを含むコードの特定やコードの集約等に利用される．このように，コードクロー

図 1 は，あるオープンソースソフトウェアのソースコードのンの検出は同様の機能を持つコードの特定の手段として利用さ一部である．このように，ソースコードには簡単なプログラムれることが多い．さまざまなコードクローン検出の方法が提案

文のみからなるコード (例えば，259 行目) や複雑な式 (例えば，されているが，よく利用されるのは字句単位の検出や抽象構

269 行目) を持つコードが存在する．このような簡単なコード

文木を利用した検出である．字句単位の検出では，字句解析にと複雑なコードの混在は，メトリクス計測やソースコード解析

よってソースコードは字句の列へと変換される．そして連続しに悪影響を与える恐れがある．

て一致する字句の部分列がコードクローンとして検出される．

メトリクス計測の例として行数を計測する場合を考える．行

抽象構文木を利用した検出では，構文解析によってソースコー

数はソースコードの規模を表すメトリクスである．より有意なドから抽象構文木が構築される．そして，同形の部分木がコー

行数を計測するために，空白行やコメント等を除外した行数がドクローンとして検出される．ソースコード中に機能的に同一計測されることが多い．行数メトリクスを，そのソースファイ

な 2 つのコード片があるとする．片方は，簡単なプロブラム文

ルが含んでいる機能の量やフォールトプローンモジュールの特のみで構成されている．もう片方は複雑な式が入り組んだ構造

定の際の指標にする場合，簡単なコードと複雑なコードの混在を持っているとする．ことような場合，既存のコードクローン

は，指標としての精度を劣化させる要因となりうる．例えば，検出手法では，それらをコードクローンとして検出することは複雑なコード 50 行と簡単なコード 100 行ではどちらが機能的難しい．
そこで本研究では，複雑な文や式を複数の簡単な文へと分解—2—

261 else

生成された変数宣言文を表す部分木ASTの部分木メソッド呼び出し式(Method invocation expression)

262 return=

後置式
STEP1: 後置式を右辺に(Postfix expression) 持つ変数宣言文を生成

262 charAt

262 eolString

261 else

262 ++

262 returnint

262 ++$24

262 lastPos

262 charAt$24

262 eolString

STEP2: メソッド呼び出し式を右辺に持つ変数宣言文を生成
262 lastPos

生成された変数宣言文を表す部分木

261 else

文を表す頂点=262 return=

式を表す頂点
その他の頂点
頂点内の数字は，ソースコード中での位置（行番号）を表す

int

262 ++char$24

262 lastPos$25

262 charAt

262 eolString

$25

$24

図 3 提案手法による AST 変換処理の様子する手法を提案する．本研究ではこの分解を平坦化と呼ぶ．平•分岐やループの条件式を表す頂点

坦化によって，ソースコード中から複雑に入り組んだ文や式は•for 文の初期化式，更新式を表す頂点

なくなる．そのため，一行あたりの機能量が均一化され，行数

JDT の AST では，以下を除いた式を表す頂点が抽出対象でメトリクスの値がより有意になることが期待される．また，振ある（表 1 は抽出対象の頂点に対応する JDT 内のクラスの一覧

る舞いが同一なコードがより類似した構造を持つようになるたである）．

め，それらをコードクローン検出手法を利用して見つけやすく•

変数の参照を表す式

なると期待される．

•

数値や文字等のリテラルを表す式•

null を表す式

図 2 は，図 1 のソースコードを提案手法により変換したものである．元のソースコードの 262 行目が変換後の 286∼288，

図 3 は，提案手法による平坦化の様子を表している．この図269 行目が変換後の 297∼299 に該当する．複雑な文や式が複数の左上の AST は図 1 の 261 行目および 262 行目のコードを表の簡単な文や式に分解されているのがわかる．

している．部分木の操作は深さ優先探索の後順にて行われる．

4. 提 案 手 法

この例の場合は，後置式が抽出対象の部分木の根頂点として判定される．そのため，この後置式を右辺に持つ変数宣言文を

ここではソースコードの平坦化手法を提案する．提案手法はAST に追加する．そして，抽出された箇所には追加された変数

抽象構文木（以降，AST）の実装に強く依存するため，本論文で宣言文において宣言された変数の参照が置かれる．後置式の抽は Java のソースコード解析ツール Java Development Tools（以出後，再度この AST は走査され，メソッド呼び出し式が抽出対

降，JDT）が構築するを対象として提案手法の説明を行う．

象の部分木として判定される．後置式と同様の処理が行われ，平坦化は AST を操作することにより行う．AST に存在している対象の部分木を走査し，平坦化条件が成り立つかどうかを判定する．平坦化条件が成り立つ場合には，抽出対象の部分木

メソッド呼び出し式を右辺として持つ変数宣言文が追加される．
この処理を抽出対象の式が見つからなくなるまで繰り返す．
図 4 は，提案手法を利用した別の変換例である．この図の左を抽出して，その部分木を右辺として持つ変数宣言文の部分木を生成する．抽出対象の部分木は，生成した変数宣言文におい表 1 JDT における抽出対象の AST 頂点て宣言された変数の参照に置換する．なお，提案手法により追ArrayAccess

ArrayCreation

加された変数宣言文において宣言された変数は，その右辺の式

ArrayInitializer

CastExpressionの型を利用する．これにより，平坦化後のコードはコンパイル

ClassInstanceCreation

ConstructorInvocation

および実行可能なコードとなる．

JDT の AST では，以下の頂点が平坦化の候補となる部分木である．

•

ExpressionMethodReference InfixExpresssion
InstanceofExpression

MethodInvocation

PostfixExpression

PrefixExpression

SuperConstructorInvocation

SuperMethodInvocation

文を表す頂点—3—

平坦化されたコード

元のソースコード…
final File file = new File(path);if ((null != file.getParentFile()) &&!file.getParentFile().exists()) {final boolean made =file.getParentFile().mkdirs();
assert made : "illegal state.";}…
for (int i = 0; i < text.length(); i++) {out.write(text.charAt(i));}…

…
final File file = new File(path);java.io.File $4 = file.getParentFile();boolean $5 = null != $4;
java.io.File $6 = file.getParentFile();boolean $7 = $6.exists();
boolean $8 = !$7;
if ($5 && $8) {java.io.File $9 = file.getParentFile();final boolean made = $9.mkdirs();
assert made : "illegal state.";}…
int $10 = text.length();for (int i = 0; i < $10; i++) {char $11 = text.charAt(i);out.write($11);$10 = text.length();
}
…

(1)

(2)

(1) 複雑な幾重にも展開される(2) ループの条件式の展開では，複数の同じ文が現れる

図 4 実装したツールを用いた変換の例

側は平坦化前のコードを表している．if 文の条件式が非常に複90雑であり，その条件式から 5 つの変数宣言分が抽出されている

80

ことがわかる．このように提案手法は，対象の式が複雑であればあるほど，幾重にもその中に存在している式を変数宣言文として抽出する．
この図では for 文の条件式も平坦化の対象である．for 文のよ

70
60

行
数
増
加
率

50
40
30

うなループの条件式の抽出では，ループの前に変数宣言文が追20加され，そのループの最後に同じ変数への代入文（注 1）が追加さ

100

れる．ループの条件式をこのように平坦化することにより，平-10

坦化前のコードと実行結果が同じになることが期待できる．

5. 適 用 実 験

0

50K

100K

150K

200K

250K

300K

350K

平坦化前プロジェクト行数

図 5 平坦化によるプロジェクト単位での行数の変化の様子

提案手法の適用実験として以下の 2 つを行った．
実験 A

平坦化によって行数メトリクスの計測結果およびコー

ドクローンの検出結果がどのように変化するのかを調査．

図 5 はプロジェクト単位での行数の変化の様子を表している．この図の縦軸に記載されている行数増加率は以下の計算式

実験 B 平坦化によって行数メトリクスとバグとの相関の度合で算出される．なお，LOCori ，LOC f la はそれぞれ元のコードのいが程度変化するのかを調査．

行数，平坦化後のコードの行数を表す．

以降，各実験について詳細に述べる．

5. 1 実験

行数増加率 = 100 ∗A(LOC f la − LOCori )LOCori

実験 A では，著者らが過去の研究 [9] で構築したデータセッ

この図より，プロジェクトが小規模であるほど，平坦化によりトを利用した．このデータセットは，2 つのパッケージからな

増加する行数の割合のばらつきが大きいことを表す．元のコーり，各パッケージにはそれぞれ 84 と 500 のソフトウェアのソードが 25,000 行以下の場合では，平坦化により行数が 1.5 倍以上

スコードが含まれている．表 2 により詳細な規模のデータを載になったプロジェクトも幾つか存在している．その一方で，プせる．このデータセットでは，テストコードやコンパイラコン

ロジェクトの規模が 100,000 行を超えるような場合では，行数

パイラ等による自動生成コードが手作業により注意深く取り除変化率は 20∼35%程度の範囲に収まっている．この結果から，かれている．

プロジェクトの規模が小規模であるほど一行あたりの密度にばらつきが大きく，行数の値を意思決定の基準としないほうが良
表 2 実験 A の対象プロジェクト

パッケージ
プロジェクト数
ファイル数
総行数

いことがわかる．

APACHEUCI

図 6 はプロジェクト単位でのコードクローン検出数の変化

84

500

の様子を表している．この図の縦軸に記載されているクローン

66,72460,548

11,545,556 10,073,635

検出数増加率は以下の計算式で算出される．なお，CLONEori ，

CLONE f la はそれぞれ元のコードから検出されたコードクロー（注 1）：厳密には，Java および JDT には代入文という概念はない．ここでは代入
演算子 “=” を持つ二項演算式を含む式文を，便宜上代入文と呼ぶ．

ンの数，平坦化後のコードから検出されたコードクローンの数
を表す．

—4—

3500

145
146
147
148
149
150
151
152
153
154
155
156
157
158
159

3000

ク
ロ
ー
ン
検
出
数
増
加
率

2500
2000
1500
1000
500
0
-500

0

50K

100K

150K

200K

250K

300K

350K

平坦化前プロジェクト行数

図 6 平坦化によるプロジェクト単位でのクローン検出数の変化の様子

クローン検出数増加率 = 100 ∗(CLONE f la −CLONEori )CLONEori

299
300
301
302
303
304
305
306
307
308
309
310
311
312
313

…
public static synchronized void closeTerminal(PosScreen pos) {if (!mgrLoggedIn) {pos.showDialog(“dialog/error/mgrnotloggedin”);
return;}Object $23 = pos.getSession();PosTransaction trans = PosTransaction.getCurrentTx($23);
Object $24 = trans.isOpen();if (!$24) {pos.showDialog(“dialog/error/terminalclosed”);
return;}Output output = pos.getOutput();
Input input = pos.getInput();
if (input.isFunctionSet(“CLOSE”)) {…
public static synchronized void voidOrder(PosScreen pos) {if (!mgrLoggedIn) {pos.showDialog(“dialog/error/mgrnotloggedin”);
return;}
XuiSession session = pos.getSession();PosTransaction trans = PosTransaction.getCurrentTx(session);Object $79 = trans.isOpen();if (!$79) {pos.showDialog(“dialog/error/terminalclosed”);
return;}Output output = pos.getOutput();
Input input = pos.getInput();
boolean lookup = false;
…

コ
ー
ド
ク
ロ
ー
ン
と
し
て
検
出

この図より，行数と同様に，プロジェクトの規模が小さいほど平坦化により新たに検出されるコードクローンの数にばらつき

図 7 平坦化により新しく検出されたコードクローンがあることがわかる．20,000 行以下のプロジェクトでは，10倍以上のコードクローンが検出される場合もあった．その一方はリリース日を終点とする 6 ヶ月間に報告されたバグであり，で，プロジェクトのサイズが 100,000 行を超える場合にはほと

リリース後バグとはリリース日を起点とする 6 ヶ月間に報告さんどの場合において，クローンの検出量は 5 倍以内で収まってれたバグを表す．なお，表示文字列の綴りが間違っている等のいる．このことから，平坦化を行うことによって非常に多くのささいなバグは除外されている．ソースコード種別の「リリーコードクローンが見つかるようになることがわかる．

ス版」とは，Eclipse のウェブページで公開されているソース

図 7 は，平坦化によって新たに検出されたコードクローンを

コードをそのまま用いたことを意味している．「書式統一」と表している．146∼158 行のコード片のうち，150 行目と 151 行

は，コメントの削除およびフォーマットの統一を行ったソース

目は元のソースコードでは 1 つの文であった．それに対して，

コードを意味している．「書式統一 + 平坦化」とは更に提案手

300∼312 行のコード片の 304 行目および 305 行目は元のソー法により平坦化を行ったソースコードである．

スコードでもこの状態であった．この差異により，元のソース

この表より，リリース前バグについては，平坦化を行うこと

コードでは２つのコード片はコードクローンとして検出されてによってどのバージョンについても行数とバグとの相関が高くいなかった．平坦化を行うことにより，この実装方法の異なるなっていることがわかる．リリース後バグについてはバージョ

コード片が既存のクローン検出手法を利用することで検出でン 3.0 では相関が低くなったが，2.0 および 2.1 では高くなった

きた．

ことがわかる．このように，平坦化を行ったソースコードの行

5. 2 実験B

実験 B では Timmermann らの研究 [24] で用いられたバグのデータセットを利用した．このデータセットは彼らのウェブサイトで公開されている（注 2） このバグデータセットの対象は，Eclipse のバージョン 2.0，2.1，3.0 のソースコードであり，それらは別途ダウンロードする必要がある（注 3）．

数は，そのままの状態のソースコードの行数や書式統一を行ったソースコードの行数に比べてバグとの相関が高くなることが多いという結果であった．

6. お わ り に
本稿では，ソースコード中の複雑なプログラム文や条件式を実験は以下の手順で行った．ダウンロードしたソースコード
に対して平坦化を行った．平坦化する前の行数と平坦化した後の行数をバグデータセットのメトリクスに追加した（注 4）．付属

表 3 JDT における抽出対象の AST 頂点バージョンの R スクリプトを実行し，得られた数値を確認した．数値は，見つかったバグ数の降順で並び替えられたファイルと，行数の2.0

降順で並び替えられたファイルとの間の Spearman の順位相関係数の値である．結果を表 3 に示す．なお，リリース前バグと2.1（注 2）：https://www.st.cs.uni-saarland.de/softevo/bug-data/eclipse/（注 3）：http://archive.eclipse.org/eclipse/downloads/（注 4）：バグデータセットのメトリクスとは，全ての対象ファイルについて，発見されたバグの個数と種々のメトリクスの値が保存されている CSV 形式のデー

3.0

ソースコード種別

リリース前バグ

リリース後バグ

リリース版

0.38730.3481

書式統一

0.39380.3566

書式統一 + 平坦化

0.39940.3623

リリース版

0.42160.2514

書式統一

0.42060.2516

書式統一 + 平坦化

0.42600.2540リリース版

0.42270.3401

書式統一

0.42350.3391

書式統一 + 平坦化

0.42550.3396

タである．

—5—

複数の簡易なプログラム文に分解する手法を提案した．提案手法を適用することで，ソースコード中一行あたりの機能の量が均一化されるため，行数メトリクス等の値がより優位になるこ[10]とが期待される．また，ソースコードの構造がある程度統一されるため，そのままのソースコードからは見つけることが難しかったコードクローンを見つけることができるようになると期

[11]

待される．
提案手法はツールとして実装され，著者のウェブページにて公開されている（注 5）．作成したツールを用いて実験を行い，提[12]

案手法を評価した．実験の結果，提案手法を適用することで大幅に行数メトリクスの値が増加するソースファイルが多数ある[13]

ことが確認できた．また，提案手法を用いることでファイルの行数メトリクスの値とそのファイルに存在しているバグの有無がより高い相関関係を保つ場合が多いことが確認された．さら[14]に，提案手法を適用したソースコードからはより多くのコード
クローンが検出されることを確認した．

[15]

今後の課題としては，提案手法を適用することによって生成されたプログラム文のうち，同一のものが多数ある場合はそれらを 1 つにまとめることが挙げられる．このようなリファクタ[16]

リングをすることによって，ソースコードがより簡潔な保守しやすい構造になる．

謝

[17]

辞

[18]

本研究は，科学研究費補助金基盤研究 (S)(課題番号：25220003)
および基盤研究 (B)(課題番号：17H01725) の助成を得て行われた．
文

献[1] M. Acharya, T. Xie, J. Pei, and J. Xu. Mining API Patterns As Partial
Orders from Source Code: From Usage Scenarios to Specifications.
In Proceedings of the the 6th Joint Meeting of the European Software
Engineering Conference and the ACM SIGSOFT Symposium on The
Foundations of Software Engineering, pages 25–34, 2007.
[2] Z. Ammarguellat. A Control-Flow Normalization Algorithm and
Its Complexity. IEEE Transactions on Software Engineering,18(3):237–251, Mar. 1992.
[3] H. A. Basit, S. J. Puglisi, W. F. Smyth, A. Turpin, and S. Jarzabek.
Efficient Token Based Clone Detection with Flexible Tokenization.
In The 6th Joint Meeting on European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations ofSoftware Engineering: Companion Papers, pages 513–516, 2007.
[4] D. Bruschi, L. Martignoni, and M. Monga. Code Normalization for
Self-Mutating Malware. IEEE Security and Privacy, 5(2):46–54,
Mar. 2007.
[5] C. Catal and B. Diri. A Systematic Review of Software Fault Prediction Studies. Expert Systems with Applications, 36(4):7346–7354,
2009.
[6] J. R. Cordy. The TXL Source Transformation Language. Science ofComputer Programming, 61(3):190–210, Aug. 2006.
[7] S. Ducasse, O. Nierstrasz, and M. Rieger. On the effectiveness ofclone detection by string matching: Research articles. Journal of
Software Maintenance and Evolution, 18(1):37–58, Jan. 2006.
[8] N. E. Fenton and S. L. Pfleeger. Software Metrics: A Rigorous andPractical Approach, Third Edition. PWS Publishing Co., Boston,
MA, USA, 3rd edition, 2014.
[9] Y. Higo and S. Kusumoto. How Should We Measure Functional
Sameness from Program Source Code? An Exploratory Study on

[19]

[20]

[21]

[22]

[23]

[24]

Java Methods. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, pages
294–305, 2014.
B. Hummel, E. Juergens, L. Heinemann, and M. Conradt. ndexbased Code Clone Detection: Incremental, Distributed, Scalable. In
Proceedings of the 2010 IEEE International Conference on Software
Maintenance, pages 1–9, 2010.
E. Juergens, F. Deissenboeck, and B. Hummel. CloneDetective – A
Workbench for Clone Detection Research. In Proceedings of the 31st
International Conference on Software Engineering, pages 603–606,
2009.
E. Juergens, F. Deissenboeck, B. Hummel, and S. Wagner. Do code
clones matter? In Proceedings of the 31st International Conference
on Software Engineering, pages 485–495, 2009.
R. Koschke. Software Visualization in Software Maintenance, Reverse Engineering, and Re-engineering: A Research Survey. Journalof Software Maintenance, 15(2):87–109, 2003.
D. Lawrie, C. Uehlinger, and D. Binkley. Vocabulary Normalization Improves IR-based Concept Location. In Proceedings ofthe 2012 IEEE International Conference on Software Maintenance,
pages 588–591, 2012.
V. B. Livshits and M. S. Lam. Finding Security Vulnerabilities inJava Applications with Static Analysis. In Proceedings of the 14th
Conference on USENIX Security Symposium - Volume 14, pages 18–
18, 2005.
J. I. Maletic, M. L. Collard, and A. Marcus. Source Code Files
As Structured Documents. In Proceedings of the 10th International
Workshop on Program Comprehension, pages 289–292, 2002.
T. Mens and T. Tourwé. A Survey of Software Refactoring. IEEE
Transactions on Software Engineering, 30(2), 2004.
H. Murakami, K. Hotta, Y. Higo, H. Igaki, and S. Kusumoto. Folding
Repeated Instructions for Improving Token-Based Code Clone Detection. In Proceedings of the 2012 IEEE 12th International Working
Conference on Source Code Analysis and Manipulation, pages 64–
73, 2012.
D. Rattan, R. Bhatia, and M. Singh. Software Clone Detection: A Systematic Review. Information and Software Technology,
55(7):1165–1199, 2013.
V. Raychev, M. Vechev, and E. Yahav. Code Completion with Statistical Language Models. In Proceedings of the 35th ACM SIGPLAN
Conference on Programming Language Design and Implementation,
pages 419–428, 2014.
C. K. Roy and J. R. Cordy. NICAD: Accurate Detection of Near-Miss
Intentional Clones Using Flexible Pretty-Printing and Code Normalization. In Proceedings of the 2008 The 16th IEEE International
Conference on Program Comprehension, pages 172–181, 2008.
M.-A. D. Storey, D. Čubranić, and D. M. German. On the Use of
Visualization to Support Awareness of Human Activities in Software
Development: A Survey and a Framework. In Proceedings of the2005 ACM Symposium on Software Visualization, pages 193–202,
2005.
F. Zhang and E. H. D’Hollander. Using Hammock Graphs to
Structure Programs. IEEE Transactions on Software Engineering,30(4):231–245, Apr. 2004.
T. Zimmermann, R. Premraj, and A. Zeller. Predicting Defects for
Eclipse. In Proceedings of the Third International Workshop on Predictor Models in Software Engineering, pages 9–15, 2007.

（注 5）：https://github.com/YoshikiHigo/JCodeFlattener—6—