ICSE 2011 Refactoring Your Lei I

1. ICSE 2011Refactoring Your Lei I Refactored! 東工大 佐伯研（incl. OB） 先鋒 SirinutThangthumachit中堅 林 晋平大将 風戸 広史

2. Transformation for Class Immutabilityby F. Kjolstad, D. Dig, G. Acevedo, and M. Snir • MutableClass → Immutable Class • 面倒 • 時間かかる • ミスしやすい • 自動化しよう • 速くて、手動より効率がいい • 本研究 • 自動化し、ツールを作った • 人手より700倍速い • 正確で、変換ミスはしない

3. 事例 Transformation for Class Immutability, Figure 1より引用

4. Immutator • プログラム解析 • 全体ではなく、注目するクラスとその呼出メソッドだけ • 事前条件確認 • 親クラスは Mutable 状態を持たない • Mutable 状態を追加できるサブクラスを持たない • 変換したいメソッドの戻り値は void、かつ Override ではない • 入出オブジェクトは clone() を持つ、または追加可能 • 変換 • クラスとフィールドを final に • コンストラクタを生成 • ターゲットメソッドを変換 • 入出オブジェクトを clone() に http://refactoring.info/tools/Immutator

5. 評価 • 適用可能性 • 対象　JutilCoal 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倍 • MacbookPro 4.1, 2.4GHｚ Core 2 Duo Transformation for Class Immutability, Table 1, 2, 3より引用

6. Refactoring Pipe-like Mashupsfor End-User Programmersby K. T. Sotlee and S. Elbaum • Yahoo! Pipes に代表されるパイプ式のマッシュアップをリファクタリング • SE の知見であるリファクタリングがエンドユーザプログラミングに適用された初の試み • 貢献 • マッシュアップ例8051個から蔓延の激しい臭いを特定 • 臭いの影響を被験者評価 • 臭いの検出/リファクタリングをformal に定義 & 自動化

7. パイプリファクタリング: Before After パイプの臭い： Duplicate Modules: 重複したモジュール Unnecessary Module: 不要なモジュール Isomorphic Paths: 同型のパス Duplicate Strings: 重複するフィールド値 パイプユニッシュリファクタリング： Collapse Duplicate Paths: 重複パスを束ねる Remove Non-Contributing Modules: 不要を削除 Extract Local Subpipe: 共通パイプとして集約 Pull Up Module: 重複フィールドを括りだし 1 4 1 2 3 3 4 Refactor “Refactoring Pipe-like Mashups for End-User Programmers”, Figure 1, 2 より引用

8. リファクタリングと臭い • 9種類のリファクタリング • 10種類（小分類もカウントすれば18）の臭い • 既存のパイプにどういった種類の臭いがあるかのデータも提示 • E.g. 32%のパイプにDuplicate Strings • 被験者実験 • RQ1: 臭いパイプよりも臭くないパイプのほうを好む • Yes: 24％vs. 63% • RQ2: 臭いパイプは臭くないパイプよりも理解が困難 • Yes: 正解率67% vs. 正解率80％

9. 評価 • 既存パイプの多くの臭いを除去できた • 複数の臭いがある場合: 貪欲（Greedy）な解決が有効 “Refactoring Pipe-like Mashups for End-User Programmers”, Table 2 より引用

10. Refactoring Java Programs for Flexible Lockingby 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 ロックを使い分けた

11. 例題 ReentrantLockをReadWriteLockに置き換え synchronized 修飾子をReentrantLockに置き換え // これもチェックする! SyncMapsm =newSyncMap(map); synchronized(sm) { … } Max Schäfer, M. Sridharan, J. Dolby, F. Tip : “Refactoring Java Programs for Flexible Locking”, In Proc. ICSE 2011,Figure 1 より引用

12. 提案手法 (Convert to Reentrant Lock) • How: モニタ式 { synchonized文, notify(), wait(), etc. } をロック API の呼び出しに置換 • Where: ロックオブジェクトl(e)をどこに導入するか Max Schäfer, M. Sridharan, J. Dolby, F. Tip : “Refactoring Java Programs for Flexible Locking”, In Proc. ICSE 2011,Figure 2 より引用

13. 評価 • 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 より引用

14. Photo Credit • http://www.flickr.com/photos/lady_fox/3986972403/