神谷年洋, "任意粒度機能モデルコードクローン検出手法のリファクタリング理解への適用の試み", 電子情報通信学会技術研究報告書, Vol.115, No.248, pp.41-46 (2015-10-14).

1. 任意粒度機能モデルコードクローン検出手法の
リファクタリング理解への適用の試み
神谷 年洋
はこだて未来大学
kamiya@fun.ac.jp
電子情報通信学会技術研究報告, Vol.115, No.248, pp.41-46 (2015-10-14).

2. 任意粒度機能モデルコードクローン検出手法の
リファクタリング理解への適用の試み
神谷 年洋
はこだて未来大学
kamiya@fun.ac.jp
島根大学大学院総合理工学研究科
kamiya@cis.shimane-u.ac.jp

3. （注）今回の検出手法は（2013年5月, 同7月のSIGSSで
発表）とはアルゴリズム／データ構造が異なる。
2015年1月発表のコード検索手法に近い。
あらすじ
●
目的: リファクタリングの分析
●
背景: AGMクローン
– 動的解析により、実行トレースが類似するコード断片を検出
– 検出した類似コード断片を手続きの呼び出し関係のグラフとして
視覚化
●
アプローチ: リファクタリング検出に向けた拡張
– 複数のリビジョンの間での類似を検出
– リビジョン間の類似と差異を視覚化
●
実験
– オープンソースプロダクトのstackitを対象とした予備的な実験

4. ソフトウェアの変更を理解する
●
ソフトウェアはさまざまな目的で変更される
– 機能拡張
– 不具合の修正
– リファクタリング（後述）
●
ソフトウェアの変更の履歴を知る → 保守上の問題を理解する
●
変更履歴を分析／利用する研究が行われている
– リスク、コスト、品質
– テスト
– 変更の粒度（バージョン管理システムによって記録された「変更」
⇔ 人間がひとつの「変更」だと思うもの）

5. リファクタリングとは？
●
Eclipseのリファクタリングメニュー？
– メソッドの名前を変更 → そのメソッドを呼び出している箇所も名
前が変わったメソッドを呼び出すように修正される
– メソッドの一部を取り出した新しいメソッドを定義（プルアップ）→
元のコードは新しく作られたメソッドの呼び出しに修正される
●
一般にはソフトウェアの外部の振る舞いを保ったまま内部の構造
を改善する修正のことを指す
●
コードを「健康」に保つ
– 修正しやすく、理解しやすく、バグが見つかりやすく

6. リファクタリングの特定、理解
●
リファクタリングをその他の種類の変更と区別したい
– その他の種類の変更と同時にされることも
– 開発者の記述（コミットログ）はときに曖昧
●
「Refactoring + PEP8 compliance」「Add entry points
and deletes shell」「Adding API key, fixing stderr
redirect」「 Removing embarrassing past script」
●
リファクタリングを区別することで
– テスト: リグレッションの判断基準（修正前後で同じテストが通る
べき？）
– ソフトウェアの理解: アーキテクチャや構造の問題の切り分け

7. コードクローンとは？
●
「コードクローン」「重複コード」「コピペ」
– 「重複したロジックは修正が難しい」
●
定義: 互いに類似したコード断片の集合
●
手法: コードクローン検出手法、分析手法、管理手法
– 「保守上の問題になるコードクローンはどんなもの？」
●
応用: リファクタリング、コードの剽窃の検知（著作権管理）
コピペ
バグ発見，
修正
修正したはず
のバグが再現

8. AGMクローン検出
●
動的解析を用いたコードクローン検出手法
●
概略
– 対象となるプログラムを実行して実行トレースを取得し、
– 実行トレース内の類似した部分列を特定し、
●
実行トレースを手続き呼び出しの列とみなす
●
呼び出している手続きの集合の類似性
– 特定した部分列に対応するソースコード内のコード断片を求め
て、コードクローンとして出力する
●
特徴: 検出されるコードクローンはソースファイル中で必ずしも連続し
ていない
– （複数の手続きにまたがっていることがある）
任意粒度機能モデル 動機
「ソースコードが多少書
き換えられてもコードク
ローンを検出したい」

9. AGMクローン検出処理のステップ
（１）紐付き風船(SB)の生成
– 紐付き風船とは、実行トレースの部分列とそのソースコード内で
の位置を表現するためのデータ構造
– 詳細は後述
（２）類似SB集合の特定
（３）冗長なSBの除去

10. （１）SBの生成
※ 説明の都合上、コールツリーを使っているかのように話しますが、実装ではコール
ツリーではなく実行トレースを利用します
main()
os.listdir()
print_extensions
_w_for_stmt()
print_extensions
_w_map_func()
os.path.
splitext() print str.join()get_extensions() print
map()
lambda() at line 8
os.path.
splitext()

11. （１）SBの生成 (つづき)
main()
os.listdir()
print_extensions
_w_for_stmt()
print_extensions
_w_map_func()
os.path.
splitext() print str.join()get_extensions() print
map()
lambda() at line 8
os.path.
splitext()
print_extensions_w_map_func()
main()
get_extensions(),
map(),
lambda() at line 8,
os.path.splitext(),
print,
str.join()
それぞれの節点
について その節点からコールツリーの
根に向かうパスを「紐」とし、
その節点から（直接あるいは間接的に）
呼び出される節点のラベルの集合を
「風船」とする

12. （２）類似SB集合の特定
●
類似した風船部分を特定（頻出アイテム集合を求めるアルゴリズム
により）
print_extensions_w_map_func()
main()
get_extensions(),
map(),
lambda() at line 8,
os.path.splitext(),
print,
str.join()
print_extensions_w_for_stmt()
main()
os.path.splitext(),
print
main()
get_extensions(),
map(),
lambda() at line 8,
os.listdir(),
os.path.splitext(),
print,
print_extensions_w_for_stmt(),
print_extensions_w_map_func(),
str.join()
{ os.path.split(), print }
{ get_extensions(), map(), lambda() at line 8, os.path.split(), print, str.join() }

13. （３）冗長なSB集合の除去
●
ソースコード中の同じ場所から（ループの繰り返しのたびに）生成されるSB
– → 紐が同じ
●
呼びだされている手続き(callee)のSBと呼び出している手続き(caller)のSB
– → calleeの紐 ⊃ callerの紐
print_extensions_w_map_func()
main()
get_extensions(),
map(),
lambda() at line 8,
os.path.splitext(),
print,
str.join()
print_extensions_w_for_stmt()
main()
os.path.splitext(),
print
main()
get_extensions(),
map(),
lambda() at line 8,
os.listdir(),
os.path.splitext(),
print,
print_extensions_w_for_stmt(),
print_extensions_w_map_func(),
str.join()
{ os.path.split(), print }

14. AGMクローンの視覚化
●
検出された類似SBの集合のそれぞれ
について
– 基準節点を根とするコールツリー
の部分木を求める
– ラベルが同じ節点をまとめる
– 基準節点▶ 単一の矩形で囲う
→ コードクローンに相当する
コード断片を含む手続き
– 風船に相当する節点▶ 灰色で表示
→ それらコード断片の共通点
（共通して呼び出す手続き）
– 上記以外の節点▶
→ それらコード断片の間の差
異
print_extensions
_w_for_stmt()
print_extensions
_w_map_func()
print
str.join()get_extensions()
map()
lambda() at line 8
os.path.
splitext()
共通点と差異の分析のための

15. リファクタリング分析
●
本研究で検出できる（したい）リファクタリング
– コード断片がある手続きpから別の手続きqに移動。p内の、そのコー
ド断片があった部分はqの呼び出しが書かれる
– プログラムを実行すると、元のプログラムとだいたい同じタイミング
でそのコード断片が実行される
●
リファクタリングカタログでは
– {Extract,Inline,Move,Pull up} Method, Rename Methodなど
def p():
p()
旧 新

16. 手法の拡張
検出手法
●
新旧のソースコードの間のコードクローンを検出する
– SBの紐や風船のラベルには新旧を表すマークを付加する
●
クローンを検出した後に「(4) リファクタリングの特定」を行う
– コードクローンに含まれる新旧SBを比較したとき
➢ 紐が同じ新SBと旧SBのペアがある → 移動していないコード断
片(Cunr)と判断
●
紐が同じ ⇔ エントリポイントから全く同じ呼び出し階層でそ
のコード断片に到達する
➢ そのようなペアがない → 移動したコード断片(Crfd)と判断

17. 予備的な実験: セットアップ
●
実装: Pythonで記述（実行トレース取得ツール 487行 + AGMクロー
ン検出および視覚化ツール 2894行）
●
検出パラーメータ
– 基準節点から手続き呼び出しの深さが 4 以内
– 共有する手続きが5個以上のコードクローン
●
対象プログラム: stackit
(https://github.com/lukasschwab/stackit)
– CLI。質問をタイプすると開発者向け QA サイトである
stackoverflowで検索を行い，検索結果のテキストを表示する
●
外部の振る舞いの等価性の判定: 同じ質問を入力したときの検
索結果のテキストが同じか
– ソースコードの総行数は最新版で 245 行

18. 実験に利用したPCとパフォーマンス
●
実験用PC
– CPU Intel Core i3-4010U 1.70GHz, RAM 16GiB, SSD
●
検出ツールの実行
– 実行トレースを入力とし Cunr と Crfd を得る
– 経過時間は 86 秒から 136 秒
– ピークメモリ(peak resident memory)利用量は 187MiBから
239MiB

19. RQ
●
リファクタリング前後のプログラムに AGM クローン検出・視覚化を
適用することで
●
(RQ1) リファクタリングの特定が可能か
– あるバージョン（リビジョン）の修正にリファクタリングが含まれて
いるかを数値(Crfd, Cunr)で判断できるか
●
(RQ2) リファクタリングによる構造変化の分析が可能か
– リファクタリングの内容を視覚化結果から読み取れるか

20. 実験の手順
●
リファクタリングに相当するリビジョンを特定する
– ソースコードが変更されていてプログラムの出力が変化していな
いリビジョンを特定
●
特定した各リビジョンに手法を適用
– 視覚化したものから変更内容を読み取る
– 手作業でソースコードを調べた結果と突き合わせる

21. リファクタリング相当のリビジョンを特定
●
対象プロダクト(stackit)の全リビジョン（176個）
– → (A) masterブランチのリビジョンのみ（104個）
– → (B)ソースファイル(*.py)を修正しているもの（50個）
– → 削除された行数が多いもの上位10個
●
→ そのリビジョンと(B)の系列で直前のリビジョンを実行して出力が
変化しなかったもの（6個）を適用対象とする
– @~8, @~15, @~34, @~66, @~74, @~78

23. 特定したリビジョンに手法を適用
●
CunrとCrefを求め、Crefが空では
ないならリファクタリングと判定
– 5/6は正しく判断
– @~34はデットコードの削除
●
実行されないのでトレース
に含まれない

24. 視覚化（@~15)
●
@~15（と@~16)に適用
– @~15の接点 「1.*」
– ＠~16の接点 「2.*」
1.click.types//convert_type
1.click.termui//_build_prompt
1.stackexchange.core/StackExchangeResultset/__iter__
1.stackexchange.core/StackExchangeResultset/next 1.click.termui//prompt
1.click.termui//prompt_func
1.click.utils//echo
agm.trace.hook/In/readline
agm.trace.hook/Out/write
1.click.termui//style
2.σ//focusQuestion 2.σ//promptUser
1.σ//focus_question
2.σ//printQuestion
bs4.element/Tag/prettify
html2text/HTML2Text/handle
bs4.element/BeautifulSoup/find
requests.api//get
bs4.element/Tag/__getattr__
requests.models/Response/text
bs4/BeautifulSoup/__init__
1.σ//print_question
1.σ//_search
requests.packages.urllib3.response/HTTPResponse/closed
stackexchange/Site/search_advanced
2.σ//searchTerm
warnings//_show_warning(a)
(b)
(c) (d)
(A)
(B)
(D)
(E)
略記: σ → stackit.stackit_core
printQuestion → print_question … (b)
focusQuestion →focus_question … (c)
promptUser → click.termui.prompt … (d)

25. まとめ
●
実行トレースからAGMクローンを検出する手法
– 紐付き風船データ構造
– 頻出アイテム集合
●
AGMクローンの視覚化手法
– 同一部分と異なる点を視覚化
●
リファクタリング分析への応用
– 異なったリビジョンの間でAGMクローンを検出
●
予備的な実験

26. ▶（飽和）頻出アイテム集合とは？
●
頻出アイテム集合(Frequent Item Set)
– 例: 「スーパーの客のレシートのデータから、同時に購入される商
品の組を見つけたい」
– 多くの集合（トランザクションと呼ぶ。例では「レシート」）に共通し
て含まれる要素（アイテムと呼ぶ。例では「商品」）
Apple
Cupcake
Donut
Cupcake
Donut
Eclair
Apple
Banana
Cupcake
Donut
Apple
Banana
Donut
A
C
D
C
D
E
A
B
C
D
A
B
D
A
C
D
C
D
E
A
B
C
D
A
B
D
{ Apple, Donut }
{ Cupcake, Donut }

27. ▶（飽和）頻出アイテム集合とは？ (つづき)
●
飽和頻出アイテム集合(Closed Frequent Item Set)
– サポート: そのアイテム集合を含むトランザクションの数
– 飽和: そのアイテム集合にアイテムを足したものは、そのアイテム
集合よりもサポートが小さい
●
本研究では
– あるコード断片から（直接的、間接的に）呼び出される手続きをア
イテム
– 呼び出す手続きが共通しているコード断片を求めるのに利用
A
C
D
C
D
E
A
B
C
D
A
B
D
{ Apple, Banana }は飽和頻出アイテム集合ではない
←Donutを足してもサポートが減らない