コードクローン解析に基づく デザインパターン適用候補の検出手法 井上研究室 吉田昌友 コードクローン解析に基づくデザインパターン適用候補の検出手法について， 井上研究室，吉田が発表します． 2008/02/22 特別研究発表会

概要 デザインパターンの1つであるFactory Methodパターンの適用候補を検出する手法の提案 提案手法を実装したツールの試作 対象ソフトウェアに含まれるコードクローンを解析することで適用候補を検出 提案手法を実装したツールの試作 オープンソースソフトウェアを対象とした適用実験 本研究の概要を述べます． 本研究では，デザインパターンの１つであるファクトリーメソッドパターンの適用候補を ソースコードから検出する手法を提案します． 対象となるソフトウェアに含まれるコードクローンを解析することで ファクトリーメソッドパターンの適用候補を検出します． そして，提案手法を実装したツールを試作し， オープンソースソフトウェアを対象に適用実験を行いました．

デザインパターン ソフトウェアの設計において頻繁に発生する問題に対する洗練された解決策[1] デザインパターンを利用すべき部分に利用されていないことがある 既存のソフトウェアにデザインパターンを適用することで，設計を改善する方法が提案されている[2] デザインパターンについて説明します． デザインパターンとは，ソフトウェアの設計において頻繁に発生する問題に対する， 洗練された解決策を言います． 実際のソフトウェア開発では，デザインパターンを利用することで設計が改善する部分に デザインパターンが利用されていないことがあります． そこで，既存のソフトウェアに対してデザインパターンを適用することで 設計を改善する方法が提案されています． [1] E. Gamma, et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addition Wesley, 1995. [2] J. Kerievsky, Refactoring to Patterns, Addition Wesley, 2004.

Factory Methodパターン 少ない修正で子クラスを追加可能 親クラスではオブジェクト生成のインタフェースのみ定義 子クラスにオブジェクト生成処理を記述 Creator Product 生成 createProduct : Product 少ない修正で子クラスを追加可能 ConcreteCreator1 ConcreteCreator2 ConcreteProduct1 ConcreteProduct2 createProduct : Product createProduct : Product デザインパターンの一例としてファクトリーメソッドパターンを説明します． ファクトリーメソッドパターンでは，プロダクトクラスのオブジェクトを クリエイタークラスが生成して使う構造になっています． オブジェクトの生成には，コンストラクタを直接使わず， クリエイトプロダクトメソッドを使って生成します． クリエイタークラスではプロダクトクラスのオブジェクトを生成するクリエイトプロダクトメソッドの インタフェースしか定義されていませんので， 実際にはクリエイタークラスを継承した，コンクリートクリエイターワンクラスが クリエイトプロダクトメソッドをオーバーライドしてプロダクトクラスの子クラスの オブジェクトを生成する処理を行います． この例では，クリエイトプロダクトメソッドがファクトリーメソッドと呼ばれます． ファクトリーメソッドパターンを使う利点は，例えば，プロダクトクラスに 新たに子クラスが追加され， 同様の処理をクリエイタークラスの新たな子クラスで行うように変更があっても， クリエイトプロダクトメソッドを新たにオーバーライドするだけで， 新たな子クラスを利用することができる点です． コンストラクタの変更に合わせて変更するコードが少なく， 少ない修正で子クラスを追加可能な設計になります． 質問が来ても応えられるか？ 生成 return new ConcreteProduct1(...) 生成 return new ConcreteProduct2(...)

既存のソフトウェアに対するデザインパターンの適用 対象ソフトウェアからデザインパターンの適用候補を見つけ出し，適用の是非を検討する 手順1. 書籍等に掲載されている適用条件に合う部分を見つけ出す 手順2. デザインパターンを適用するためにソースコードを修正する 手順3. 適用した結果，設計が改善したか確認する デザインパターンの適用 続いて，既存のソフトウェアに対してデザインパターンを適用する手順を述べます． まず，書籍などに掲載されているデザインパターンの適用条件に合う部分を ソースコードから見つけ出します． 次に，見つけ出した部分にデザインパターンを適用するため，ソースコードを修正します． 最後に，適用した結果，ソフトウェアの設計が改善したかどうか確認します． 適用条件を満たす ソースコード 適用後の ソースコード

Factory Methodパターンの適用例 拡張性の向上 コードクローンの減少 拡張性の問題 子クラス追加に手間がかかる コードクローンの問題 保守性が低下する一因 AbstractBuilderTest AbstractBuilderTest ・・・ builder = createBuilder(...); #builder: OutputBuilder #builder: OutputBuilder testAddAboveRoot protected abstract OutputBuilder createBuilder (...); DOMBuilderTest XMLBuilderTest HTMLBuilderTest createBuilder ・・・ builder = createBuilder(...); testAddAboveRoot testAddAboveRoot testAddAboveRoot 既存のソフトウェアに対するデザインパターンの適用について， ファクトリーメソッドパターンの適用例を示します． ファクトリーメソッドパターンの適用を検討すべきコードの特徴は， コードクローンであるメソッドが共通の親クラスを持つクラス対の間に存在する点と， コンストラクタの呼び出し文がコードクローンであるメソッドの間で異なる点です． このコードの構造には２つの問題点があります． １つは拡張性の問題であり，もう１つはコードクローンの問題です． 拡張性の問題とは， 新たに子クラスを追加して同様の処理を行うように変更があった場合， テストアッドアバブルートゥメソッドを新たに定義することになり， 拡張に手間がかかります． 次にコードクローンとは コードクローンの問題とは，テストアッドアバブルートゥメソッドが増えることにより コードクローンが増えて，保守性が低下するひとつの原因となることです． 例えば，１つのメソッドにバグが存在した場合， 他の２つのメソッドも 修正を検討しなければならなくなります． では，この例に対してファクトリーメソッドパターンを適用していきます． ２つのテストアッドアバブルートゥメソッドを親クラスにまとめたいのですが， 現在の構造では， 呼び出すコンストラクタの種類が異なるためにまとめることができません． そこで，オブジェクトの生成をファクトリーメソッドで間接的に行う構造に変更します． ２つのテストアッドアバブルートゥメソッドのコンストラクタの呼び出し文を 引数，返り値の型の等しいクリエイトビルダーメソッドに置き換えます． ２つのテストアッドアバブルートゥメソッドの内容が揃いましたので， 親クラスにまとめることができます． クリエイトビルダーメソッドを親クラスに抽象メソッドとして定義し， テストアッドアバブルートゥメソッドを親クラスに移動します． これで，ファクトリーメソッドパターンの適用ができました． ファクトリーメソッドパターンを適用したことで， 新たに子クラスを追加するように変更になった場合でも， クリエイトビルダーメソッドを新たに実装するだけで済み， 拡張性が向上し，かつ，コードクローンが減少しています． コードクローン HTMLBuilderTest DOMBuilderTest XMLBuilderTest ・・・ builder = new DOMBuilder(…); ・・・ builder = new DOMBuilder(…); ・・・ builder = new XMLBuilder(…); ・・・ builder = new HTMLBuilder(…); testAddAboveRoot testAddAboveRoot createBuilder createBuilder createBuilder ・・・ builder = new XMLBuilder(…); バグ 修正を検討しなければならない return new HTMLBuilder(…); return new DOMBuilder(…); return new XMLBuilder(…);

本研究の動機と目的 デザインパターン適用の問題点 Factory Methodパターンの適用条件に合う部分を自動的に検出する手法の実現 デザインパターンの適用条件に合うソースコードを人手で発見することは困難である 大規模ソフトウェアが対象の場合，より困難となる Factory Methodパターンの適用条件に合う部分を自動的に検出する手法の実現 コードクローンの解析 クラスの継承関係の抽出 では，本研究の動機と目的について述べます． 既存のソフトウェアにデザインパターンを適用する上での問題点ですが， デザインパターンの適用条件に合うソースコードを人手で発見することが困難であり， 大規模ソフトウェアが対象の場合，発見はより困難になると考えられます． そこで，ファクトリーメソッドパターンの適用条件に合う部分を 自動的に検出する手法を実現することで， 既存のソフトウェアに対するファクトリーメソッドパターンの適用を支援することを考えました． 提案手法は， コードクローンの解析とクラスの継承関係の抽出， この2つを用いて実現します

提案手法 Factory Methodパターンの適用条件に合う部分を検出する 条件 1 Factory Methodパターン適用前 手順 1 兄弟クラス間にメソッド単位のコードクローンが存在する Factory Methodパターン適用前 AbstractBuilderTest #builder: OutputBuilder 手順 1 コードクローンを検出し，コードクローンを含むクラスの継承関係を解析する DOMBuilderTest XMLBuilderTest testAddAboveRoot testAddAboveRoot 条件 2 呼び出すコンストラクタがメソッド間で異なる ファクトリーメソッドパターンの適用条件は２つあると考えられます． １つは，共通の親クラスを持つ兄弟クラスの間にメソッド単位のコードクローンがある という条件と， もう１つは，呼び出すコンストラクタがメソッドの間で異なるという条件です． この条件を満たす部分をソースコードから検出する手順を定めました． 条件１に対しては，コードクローンを検出し，メソッド単位のコードクローンを含む クラスの継承関係を解析して判定します． 条件２に対しては，メソッドで呼び出すコンストラクタの種類を比較することで判定します． ・・・ builder = new DOMBuilder(…); 手順 2 メソッドで呼び出すコンストラクタの種類を比較する ・・・ builder = new XMLBuilder(…);

実験用ツールの概要 入力 出力 コードクローンの検出にはCCFinder[3]を用いた Javaで記述されたソースコードファイル群 Factory Methodパターンの適用条件に合うメソッド群 それらメソッドに共通した親クラス名 コードクローンの検出にはCCFinder[3]を用いた 実装したツール 出力 以上の提案手法を実装したツールを試作しました． ジャバで記述されたソースコードのファイル群を入力とし， ツールを使って検出したコードクローンの位置情報と ソースコードを構文解析することで得たクラス継承関係から ファクトリーメソッドパターンの適用条件に合う，メソッド群の位置情報と それらメソッドに共通した親クラス名を出力します． 今回のコードクローンの検出ツールには， シーシーファインダーを使いました． 入力 コードクローンの 位置情報 CCFinder ソースコード [3] T. Kamiya, S. et al., “CCFinder: A multi-linguistic token-based code clone detection system for large scale source code”, IEEE Trans. Softw. Eng., 28(7):654-670, 2002.

実験概要 目的 対象 Factory Methodパターンの適用条件に合う部分の数の調査 Javaで記述された8つのオープンソースソフトウェア 提案手法を実装したツールを使って実験を行いました． 目的は２つあり， １つは，ソフトウェアごとのファクトリーメソッドパターンの適用条件に合う 部分の数の調査であり， もう１つはツールが検出した部分の一例に対し，実際にファクトリーメソッドパターンが 適用可能かどうかの確認です． ８つのジャバで記述されたオープンソースソフトウェアを対象にツールを実行しました．

ツールの検出部分の数 数万から数十万行の8つのソフトウェアから1～14個検出された ANTLR 32K 167 1 Ant 198K 994 ソースコードの行数 クラスの数 検出部分の数 ANTLR 32K 167 1 Ant 198K 994 2 Azureus 538K 2226 14 JBoss 679K 3372 10 JHotDraw 90K 487 SableCC 35K 237 Soot 352K 2298 9 WALA 210K 1565 6 ツールの出力した結果です． ソフトウェアごとに，入力したソースコードの行数，抽出されたクラスの数， ツールがファクトリーメソッドパターンを適用可能と判定した部分の数を示しています． 数万から数十万行の８つのソフトウェアからそれぞれ１から１４個の部分が検出されました． ツールが出力した中の，アントラーからの検出部分に対して， ファクトリーメソッドパターンの適用が実際に可能かどうか確認しました．

ANTLRへのFactory Methodパターン適用結果 CodeGenerator CodeGenerator protected abstract OOActionLexer createActionLexer(...); createActionLexer processAction ForSpecialSymbols ・・・ lexer = createActionLexer(…); ツールが提示した部分に対して Factory Methodパターンを適用できた CSharpCodeGenerator CppCodeGenerator JavaCodeGenerator CSharpCodeGenerator CppCodeGenerator JavaCodeGenerator ファクトリーメソッドパターン適用前は，コードクローンではあるのですが， それぞれの呼び出すコンストラクタが異なるために親クラスにまとめることが できなかった３つのメソッドを， コンストラクタの呼び出し文を， 名前，引数，返り値の型が等しいファクトリーメソッドに置き換えたことで 内容がそろい，親クラスにまとめることができました． 変更の前後でアントラーの振る舞いが変わっていないことを テストケースを使って確認できましたので， ツールが提示した部分に対してファクトリーメソッドパターンを適用できたことが 確認できました． processAction ForSpecialSymbols processAction ForSpecialSymbols processAction ForSpecialSymbols createActionLexer createActionLexer createActionLexer ・・・ lexer = new csharp. ActionLexer(…); ・・・ lexer = new cpp. ActionLexer(…); ・・・ lexer = new java. ActionLexer(…); return new csharp. ActionLexer(...); return new cpp. ActionLexer(...); return new java. ActionLexer(...);

考察 Factory Methodパターンを適用できた ツールの出力情報の不足 コードクローンの量を減らすことができた 適用前後で振る舞いが変化していないことを確認できた 83個のテストケースを用いて確認 ツールの出力情報の不足 減らすことのできるコードクローンの量がわからない 編集しなければならないソースコードの量がわからない 考察を述べます． ツールが提示した部分に実際にファクトリーメソッドを適用することができ， コードクローンの量を減らすことができました． また，ファクトリーメソッドパターンの適用の前後で 対称ソフトウェアのアントラーの振る舞いが変わっていないことを テストケースを使って確認できました． 実際にファクトリーメソッドパターンを適用する作業でわかった問題としては， 減らすことのできるコードクローンの量， 編集しなければならないソースコードの量が ユーザから見てわからないという問題がありました．

まとめと今後の課題 まとめ 今後の課題 Factory Methodパターンの適用条件に合う部分を自動的に検出する手法の提案 ツールの出力情報の改善 Factory Methodパターン以外のデザインパターンの適用候補の検出 まとめです． 本研究では，ファクトリーメソッドパターンの適用条件に合う部分を ソースコードから自動的に検出する手法を提案しました． 今後の課題としては， 先ほど言った出力情報の改善と， ファクトリーメソッドパターン以外のデザインパターンの適用候補の検出を考えています． 以上で発表を終わります．