Transcript 03 - qwik.jp

ICSE 2011
Refactoring Your Lei I
東工大 佐伯研（incl. OB）
先鋒 Sirinut Thangthumachit
中堅 林 晋平
大将 風戸 広史
Transformation for Class Immutability
by F. Kjolstad, D. Dig, G. Acevedo, and M. Snir
• Mutable Class → Immutable Class
– 面倒
– 時間かかる
– ミスしやすい
• 自動化しよう
– 速くて、手動より効率がいい
• 本研究
– 自動化し、ツールを作った
– 人手より700倍速い
– 正確で、変換ミスはしない
事例
Transformation for Class Immutability, Figure 1より引用
Immutator
1. プログラム解析
–
全体ではなく、注目するクラスとその呼出メソッドだけ
2. 事前条件確認
–
–
–
–
親クラスは Mutable 状態を持たない
Mutable 状態を追加できるサブクラスを持たない
変換したいメソッドの戻り値は void、かつ Override ではない
入出オブジェクトは clone() を持つ、または追加可能
3. 変換
–
–
–
–
クラスとフィールドを final に
コンストラクタを生成
ターゲットメソッドを変換
入出オブジェクトを clone() に
http://refactoring.info/tools/Immutator
評価
適用可能性
•
•
対象 Jutil Coal 0.3, jpaul 2.5.1, Apache Commons Collections 3.2.1.
110/346 *100 = 33.74%
正確性
•
•
•
Table1の実験、変換後にテストを行い、全部成功
Table2で 6つのOSS内のImmutable変換に26ミス発見
Table3で 6人のプログラマ、8クラスを変換してもらうと、51ミス
性能
•
ひとつのクラス変換は2.33秒、
• 人間は8クラスで220分、約700倍
• Macbook Pro 4.1, 2.4GHｚ Core 2 Duo
Transformation for Class Immutability, Table 1, 2, 3より引用
Refactoring Pipe-like Mashups
for End-User Programmers
by K. T. Sotlee and S. Elbaum
• Yahoo! Pipes に代表されるパイプ式のマッシュアップ
をリファクタリング
– SE の知見であるリファクタリングがエンドユーザプログラミ
ングに適用された初の試み
• 貢献
– マッシュアップ例8051個から蔓延の激しい臭いを特定
– 臭いの影響を被験者評価
– 臭いの検出/リファクタリングを formal に定義 & 自動化
パイプリファクタリング: Before After
パイプの臭い：
パイプユニッシュリファクタリング：
1. Duplicate Modules: 重複したモジュール
2. Unnecessary Module: 不要なモジュール
3. Isomorphic Paths: 同型のパス
4. Duplicate Strings: 重複するフィールド値
1. Collapse Duplicate Paths: 重複パスを束ねる
2. Remove Non-Contributing Modules: 不要を削除
3. Extract Local Subpipe: 共通パイプとして集約
4. Pull Up Module: 重複フィールドを括りだし
1
4
1
2
3
3
4
Refactor
“Refactoring Pipe-like Mashups for End-User Programmers”, Figure 1, 2 より引用
リファクタリングと臭い
• 9種類のリファクタリング
• 10種類（小分類もカウントすれば18）の臭い
– 既存のパイプにどういった種類の臭いがあるか
のデータも提示
• E.g. 32%のパイプにDuplicate Strings
– 被験者実験
• RQ1: 臭いパイプよりも臭くないパイプのほうを好む
– Yes: 24％ vs. 63%
• RQ2: 臭いパイプは臭くないパイプよりも理解が困難
– Yes: 正解率67% vs. 正解率80％
評価
• 既存パイプの多くの臭いを除去できた
• 複数の臭いがある場合: 貪欲（Greedy）な解決が有効
“Refactoring Pipe-like Mashups for End-User Programmers”, Table 2 より引用
Refactoring Java Programs for Flexible Locking
by M. Schäfer, M. Sridharan, J. Dolby, F. Tip
• 目的: Java プログラムの並行性を向上させるために、
状況に応じて排他制御の機構を容易に変更したい
• おもな貢献
– Java 組み込みのオブジェクトモニタ (synchronized) を
java.util.concurrent API (ReentrantLock / ReadWriteLock)
に置き換えるリファクタリングアルゴリズムを定義
– 支援ツール ReLocker によりその適用を自動化
– 既存 OSS に支援ツールを適用し、80%以上のオブジェクト
モニタが ReentrantLock に変更できることを示した。
– ReadWriteLock を人手で導入したプログラムと比較して、
ほとんどの場合で正しく Read/Write ロックを使い分けた
例題
ReentrantLock を
ReadWriteLock に
置き換え
synchronized 修飾子
を ReentrantLock に
置き換え
// これもチェックする!
SyncMap sm =
new SyncMap(map);
synchronized(sm) {
…
}
Max Schäfer, M. Sridharan, J. Dolby, F. Tip : “Refactoring Java Programs for Flexible Locking”, In Proc. ICSE 2011,
Figure 1 より引用
提案手法 (Convert to Reentrant Lock)
• How: モニタ式 { synchonized 文, notify(), wait(), etc. }
をロック API の呼び出しに置換
• Where: ロックオブジェクト l(e) をどこに導入するか
オブジェクト
e の型となるクラスにインスタンスフィールドを追加
クラス
e が表すクラスに静的フィールドを追加
非共有のフィールド
e = e’.f のとき、e の型となるクラスに f の兄弟としてインス
タンスフィールドを追加
Max Schäfer, M. Sridharan, J. Dolby, F. Tip : “Refactoring Java Programs for Flexible Locking”, In Proc. ICSE 2011,
Figure 2 より引用
評価
• Convert to Reentrant Lock リファクタリング
• Convert to Read-Write Lock リファクタリング
すでに Read/WriteLock を使用
しているプログラムをいったん
ReentrantLock に戻し、ツールが
どの程度 Read ロックの使用を
推論できたか (正解率)
Max Schäfer, M. Sridharan, J. Dolby, F. Tip : “Refactoring Java Programs for Flexible Locking”, In Proc. ICSE 2011,
Table 1, 2 より引用
Photo Credit
• http://www.flickr.com/photos/lady_fox/3986972403/