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 ｚ 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/