icse 2011 refactoring your lei i
DESCRIPTION
ICSE 2011 Refactoring Your Lei I. Refactored!. 東工大 佐伯研( incl. OB ) 先鋒 Sirinut Thangthumachit 中堅 林 晋平 大将 風戸 広史. Transformation for Class Immutability by F. Kjolstad , D. Dig, G. Acevedo, and M. Snir. Mutable Class → Immutable Class 面 倒 時 間かかる ミスしやす い 自動化しよ う 速くて、手動より効率がいい - PowerPoint PPT PresentationTRANSCRIPT
ICSE 2011
Refactoring Your Lei I
東工大 佐伯研( incl. OB )先鋒 Sirinut Thangthumachit中堅 林 晋平大将 風戸 広史
Refactored!
Transformation for Class Immutabilityby 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 z Core 2 Duo
Transformation for Class Immutability, Table 1, 2, 3 より引用
Refactoring Pipe-like Mashupsfor End-User Programmers
by K. T. Sotlee and S. Elbaum
• Yahoo! Pipes に代表されるパイプ式のマッシュアップをリファクタリング– SE の知見であるリファクタリングがエンドユーザプ
ログラミングに適用された初の試み• 貢献– マッシュアップ例 8051 個から蔓延の激しい臭いを特
定– 臭いの影響を被験者評価– 臭いの検出 / リファクタリングを formal に定義 &
自動化
パイプリファクタリング : Before After
“Refactoring Pipe-like Mashups for End-User Programmers”, Figure 1, 2 より引用
パイプの臭い:1. Duplicate Modules: 重複したモジュール2. Unnecessary Module: 不要なモジュール3. Isomorphic Paths: 同型のパス4. Duplicate Strings: 重複するフィールド値
2
4
3
パイプユニッシュリファクタリング:1. Collapse Duplicate Paths: 重複パスを束ねる2. Remove Non-Contributing Modules: 不要を削
除3. Extract Local Subpipe: 共通パイプとして集約4. Pull Up Module: 重複フィールドを括りだし1
Refactor
4
3
1
リファクタリングと臭い
• 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 Lockingby M. Schafer, M. Sridharan, J. Dolby, F. Tip
• 目的 : Java プログラムの並行性を向上させるために、状況に応じて排他制御の機構を容易に変更したい
• おもな貢献– Java 組み込みのオブジェクトモニタ (synchronized) を
java.util.concurrent API (ReentrantLock / ReadWriteLock) に置き換えるリファクタリングアルゴリズムを定義
– 支援ツール ReLocker によりその適用を自動化– 既存 OSS に支援ツールを適用し、 80% 以上のオブジェク
トモニタが ReentrantLock に変更できることを示した。– ReadWriteLock を人手で導入したプログラムと比較して、
ほとんどの場合で正しく Read/Write ロックを使い分けた
例題
Max Schafer, M. Sridharan, J. Dolby, F. Tip : “Refactoring Java Programs for Flexible Locking”, In Proc. ICSE 2011,Figure 1 より引用
synchronized 修飾子を ReentrantLock に置き換え
ReentrantLock を ReadWriteLock に置き換え
// これもチェックする !SyncMap sm = new SyncMap(map);synchronized(sm) { …}
提案手法 (Convert to Reentrant Lock)
• How: モニタ式 { synchonized 文 , notify(), wait(), etc. } をロック API の呼び出しに置換
• Where: ロックオブジェクト l(e) をどこに導入するか
Max Schafer, M. Sridharan, J. Dolby, F. Tip : “Refactoring Java Programs for Flexible Locking”, In Proc. ICSE 2011,Figure 2 より引用
オブジェクト e の型となるクラスにインスタンスフィールドを追加
クラス e が表すクラスに静的フィールドを追加
非共有のフィールド
e = e’.f のとき、 e の型となるクラスに f の兄弟としてインスタンスフィールドを追加
評価• Convert to Reentrant Lock リファクタリング
• Convert to Read-Write Lock リファクタリング
Max Schafer, M. Sridharan, J. Dolby, F. Tip : “Refactoring Java Programs for Flexible Locking”, In Proc. ICSE 2011,Table 1, 2 より引用
すでに Read/WriteLock を使用しているプログラムをいったん ReentrantLock に戻し、ツールがどの程度 Read ロックの使用を推論できたか ( 正解率 )
Photo Credit• http://www.flickr.com/photos/lady_fox/3986972403/