修士論文デザインパターン検出能力の向上を目的とした複数検出手法の

NAIST-IS-MT0851116
修士論文
デザインパターン検出能力の向上を目的とした
複数検出手法の併用
水野恵祐
2010 年 2 月 4 日
奈良先端科学技術大学院大学
情報科学研究科情報システム学専攻
本論文は奈良先端科学技術大学院大学情報科学研究科に
修士 (工学) 授与の要件として提出した修士論文である。
水野恵祐
審査委員：
飯田元教授
（主指導教員）
松本健一教授
（副指導教員）
安本慶一准教授
（副指導教員）
川口真司助教
デザインパターン検出能力の向上を目的とした
複数検出手法の併用∗
水野恵祐
内容梗概
デザインパターンとは，ソフトウェアの設計時によく起こる問題に対する典型
的な解決策をまとめたものである．ソフトウェアに適用されているデザインパター
ンを検出することは，ソフトウェアの構造に関する理解を深めることにつながる．
そのため，これまでに数多くのデザインパターン検出手法が提案されている．こ
れらの検出手法は，検出可能なデザインパターンの種類や検出箇所が異なってい
る．この違いはそれぞれの検出手法の検出アプローチの違いによるものであり，
それぞれの検出手法にはデザインパターン検出の適性に差があると考えられる．
本研究では，複数の検出手法を適切に併用することで，個々の検出手法の適性
を補い合い，デザインパターン検出能力を向上させることができると考えた．現
在，いくつかのデザインパターン検出手法をツールとして実装したものが Web 上
で公開されている．本研究では，これらのツールの検出結果を組み合わせること
で複数検出手法の併用を実現した．複数検出手法を併用することの妥当性を検証
した上で，複数の併用アルゴリズムの性能評価を行った．その結果，和集合によ
る併用が効果的であるという知見が得られた．
キーワード
ソフトウェア工学，デザインパターン，ソフトウェア理解，デザインパターン検
出，併用アルゴリズム
∗
奈良先端科学技術大学院大学情報科学研究科情報システム学専攻修士論文, NAIST-ISMT0851116, 2010 年 2 月 4 日.
i
Hybridization of Design Pattern Detection
Techniques for Improving Detection Ability∗
Keisuke Mizuno
Abstract
Design patterns are typical solutions to frequently occurring problems in objectoriented software design. Detection of design patterns applied in software may
help understand software architecture. Therefore, many design pattern detection
techniques have been proposed. These detection techniques detect different kinds
of design patterns, and their results are generally different. This is because they
detect design patterns in different ways, and have different ability of the design
pattern detection.
We assume that we can detect more precisely by hybridization of some design
pattern detection techniques. Some detection techniques are implemented as
a tool and released on the Web. We combine the detection results of these
tools to achieve hybridization of design pattern detection techniques. In this
paper, we validate whether hybridization improves detection ability and evaluate
performance of some hybrid algorithms.
Keywords:
Software Engineering, Design Pattern, Program Comprehension, Design Pattern
Detection, Hybrid Algorithm
∗
Master’s Thesis, Department of Information Systems, Graduate School of Information
Science, Nara Institute of Science and Technology, NAIST-IS-MT0851116, February 4, 2010.
ii
目次
1. はじめに
1
2. デザインパターン
3
2.1 デザインパターンの概要 . . . . . . . . . . . . . . . . . . . . . . .
3
2.2 デザインパターン検出 . . . . . . . . . . . . . . . . . . . . . . . .
5
3. デザインパターン検出手法
6
3.1
Pat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2
HEDGEHOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3
PTIDEJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.4
SPOOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.5
FUJABA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.6
CrocoPat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.7
SPQR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.8
Columbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.9
DPVK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.10 DPRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.11 PRAssistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.12 DPdT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.13 PINOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.14 DP-Miner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.15 WOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.16 Web 上で公開されているデザインパターン検出ツール . . . . . . .
29
4. 提案手法
32
4.1 複数検出手法の併用によるデザインパターン検出 . . . . . . . . .
32
4.2 検出範囲の統一 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.3 併用アルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
和集合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3.1
iii
4.3.2
多数決 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3.3
適性値付き和集合 . . . . . . . . . . . . . . . . . . . . . . .
35
5. 実験
37
5.1 妥当性の検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.1.1
妥当性を検証する仮説 . . . . . . . . . . . . . . . . . . . .
37
5.1.2
実験対象 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.1.3
実験 1: 検出されるデザインパターンの確認 . . . . . . . .
39
5.1.4
実験 2: 検出手法の組み合わせによる精度の確認 . . . . . .
41
5.2 併用アルゴリズムの比較評価
. . . . . . . . . . . . . . . . . . . .
42
5.2.1
実験対象 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2.2
実験方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2.3
実験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
6. 考察
46
6.1 併用アルゴリズムの性能 . . . . . . . . . . . . . . . . . . . . . . .
46
6.2 検出範囲 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.3 実験結果の妥当性 . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
7. 関連研究
48
7.1 デザインパターン検出手法の比較評価
. . . . . . . . . . . . . . .
48
7.2 デザインパターン検出手法の精度改善
. . . . . . . . . . . . . . .
48
. . . . . . . . . . . . . . . . . . . .
49
7.3 デザインパターンの影響分析
8. まとめ
50
謝辞
51
参考文献
52
付録
57
A. デザインパターン検出ツールの検出範囲
57
iv
B. デザインパターン検出ツールの検出件数
57
C. デザインパターン検出ツール間の検出箇所の一致件数
57
D. デザインパターン検出ツールおよび和集合による併用結果の検出精度
60
E. 併用アルゴリズムの検出精度
60
v
図目次
1
Pat の検出プロセス [27] . . . . . . . . . . . . . . . . . . . . . . . .
9
2
Adapter パターンの構造 [27] . . . . . . . . . . . . . . . . . . . . .
9
3
Adapter パターンの Prolog ルール [27] . . . . . . . . . . . . . . . .
9
4
デザインパターンのメタモデル [1] . . . . . . . . . . . . . . . . . .
11
5
変形した Composite パターンの訂正例 [1] . . . . . . . . . . . . . .
12
6
SPOOL のアーキテクチャ[25] . . . . . . . . . . . . . . . . . . . .
13
7
SPOOL で扱う情報 [25] . . . . . . . . . . . . . . . . . . . . . . . .
14
8
Composite パターンの定義 [29] . . . . . . . . . . . . . . . . . . . .
15
9
SPQR の検出プロセス [36] . . . . . . . . . . . . . . . . . . . . . .
17
10
RedirectInFamily パターンの構造 [36] . . . . . . . . . . . . . . . .
18
11
RedirectInFamily の σ-calculus 表現 [36] . . . . . . . . . . . . . . .
18
12
DPVK の検出プロセス [38] . . . . . . . . . . . . . . . . . . . . . .
19
13
REQL スクリプトによる Command パターンの静的な定義 [38] . .
20
14
Command パターンの動的な定義 [38] . . . . . . . . . . . . . . . .
20
15
DPRE の検出プロセス [5] . . . . . . . . . . . . . . . . . . . . . .
21
16
Adapter パターンにおけるクラス間の関係 [5] . . . . . . . . . . . .
21
17
ビジュアル言語における Adapter パターンの定義 [5] . . . . . . . .
21
18
Visitor パターンの構造 [19] . . . . . . . . . . . . . . . . . . . . . .
22
19
Visitor パターンの Prolog ルール [19] . . . . . . . . . . . . . . . .
22
20
PRAssistor のアーキテクチャ[19] . . . . . . . . . . . . . . . . . .
23
21
Decaorator パターンの構造 [40] . . . . . . . . . . . . . . . . . . .
24
22
ビジュアル言語における Adapter パターンの定義 [40] . . . . . . .
24
23
GoF のデザインパターンの再分類 [35] . . . . . . . . . . . . . . . .
26
24
DP-Miner のアーキテクチャ[9] . . . . . . . . . . . . . . . . . . . .
26
25
Adapter パターン [9] . . . . . . . . . . . . . . . . . . . . . . . . .
27
26
DPdT のスクリーンショット . . . . . . . . . . . . . . . . . . . . .
30
27
DPRE のスクリーンショット . . . . . . . . . . . . . . . . . . . . .
30
28
PINOT のスクリーンショット . . . . . . . . . . . . . . . . . . . .
31
vi
29
WOP のスクリーンショット . . . . . . . . . . . . . . . . . . . . .
31
30
提案手法の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
表目次
1
GoF の 23 種類のデザインパターン . . . . . . . . . . . . . . . . .
4
2
検出ツールが検出可能なデザインパターンの種類 . . . . . . . . .
7
3
検出ツールが着目するデザインパターンの特徴 . . . . . . . . . . .
8
4
変形したデザインパターンに対する検出手法の対応方法 . . . . . .
8
5
構造要素の素数表現 [9] . . . . . . . . . . . . . . . . . . . . . . . .
27
6
Adapter パターンのマトリクス [9] . . . . . . . . . . . . . . . . . .
27
7
既存のデザインパターン検出ツール . . . . . . . . . . . . . . . . .
29
8
統一した検出範囲 . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
9
各検出ツールの合計検出件数
. . . . . . . . . . . . . . . . . . . .
40
10
検出ツール間の検出箇所の合計一致件数 . . . . . . . . . . . . . .
40
11
各プロジェクトにおける検出ツールごとの検出精度のまとめ . . .
43
12
各プロジェクトにおける併用アルゴリズムの検出精度のまとめ . .
45
13
DPdT のデザインパターンごとの検出範囲 . . . . . . . . . . . . .
58
14
DPRE のデザインパターンごとの検出範囲 . . . . . . . . . . . . .
58
15
PINOT のデザインパターンごとの検出範囲 . . . . . . . . . . . .
59
16
WOP のデザインパターンごとの検出範囲 . . . . . . . . . . . . .
61
17
JHotDraw 6.0 beta 1 における各検出ツールの検出件数 . . . . . .
62
18
JHotDraw 5.1 における各検出ツールの検出件数 . . . . . . . . . .
63
19
JRefactory における各検出ツールの検出件数 . . . . . . . . . . . .
64
20
Lexi における各検出ツールの検出件数 . . . . . . . . . . . . . . .
65
21
JHotDraw 6.0 beta 1 における検出箇所の一致件数 . . . . . . . .
66
22
JHotDraw 5.1 における検出箇所の一致件数 . . . . . . . . . . . .
67
23
JRefactory における検出箇所の一致件数 . . . . . . . . . . . . . .
68
24
Lexi における検出箇所の一致件数 . . . . . . . . . . . . . . . . . .
69
vii
25
JHotDraw 6.0 beta 1 の Strategy パターンに関する検出ツールご
との検出精度 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
26
JHotDraw 5.1 における検出ツールごとの検出精度 (1) . . . . . . .
70
27
JHotDraw 5.1 における検出ツールごとの検出精度 (2) . . . . . . .
71
28
JRefactory における検出ツールごとの検出精度 . . . . . . . . . .
72
29
Lexi における検出ツールごとの検出精度 . . . . . . . . . . . . . .
73
30
JHotDraw 6.0 beta 1 の Strategy パターンに関する併用アルゴリ
ズムの検出精度 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
31
JHotDraw 5.1 における併用アルゴリズムの検出精度 (1) . . . . .
74
32
JHotDraw 5.1 における併用アルゴリズムの検出精度 (2) . . . . .
75
33
JRefactory における併用アルゴリズムの検出精度 . . . . . . . . .
76
34
Lexi における併用アルゴリズムの検出精度 . . . . . . . . . . . . .
77
viii
1. はじめに
デザインパターン [17] は，ソフトウェアの設計上の問題に対するベストプラク
ティスをまとめたものである．デザインパターンを利用することで，過去の成功
例を再利用することが容易となり，ソフトウェア設計を効率的に行うことができ
る．また，デザインパターンは開発者同士の共通語彙としても利用することがで
き，ソフトウェアの設計に際して，互いの意思疎通を円滑にする働きもある．こ
のようなことから，デザインパターンを利用することでソフトウェアの品質向上
が見込める [17, 42] ため，デザインパターンは多くのソフトウェア開発プロジェ
クトで利用されている．
デザインパターンはソフトウェア理解においても重要な役割を果たしている
[29, 40]．デザインパターンに含まれる要素（クラス，オブジェクトなど）には
各々の役割が規定されているため，ソフトウェアに適用されているデザインパター
ンを理解することで，要素間の関係や設計段階で想定されていた拡張性などにつ
いて知ることができるからである．このように，既存のソフトウェアに適用され
ているデザインパターンを検出することで，開発者はソフトウェアの構造に関す
る理解を深めることができ，ソフトウェアの保守が容易になる．
そのため，ソフトウェア理解の支援を目的として，既存のソフトウェアからデ
ザインパターンを検出するための手法がこれまでに数多く提案されている．こう
した検出手法の多くは Gang of Four(GoF) のデザインパターン [17] を検出対象と
しているが，GoF の 23 種類のデザインパターン全てを検出できるわけではなく，
検出手法ごとに検出可能なデザインパターンの種類が異なっている．また，同じ
種類のデザインパターンについても，検出箇所（デザインパターンが適用されて
いると検出された箇所）は，検出手法間で異なっている場合が多い．
こうした検出対象および検出箇所の違いは，それぞれの検出手法によって検出
アプローチ，つまりデザインパターンの定義やデータ構造，検出アルゴリズムな
どが異なることに起因するものである [10, 5]．また，デザインパターンを適用す
る場合には，元々定義されていた構造を変形させることもある．このような変形
したデザインパターンに対する検出能力も，検出アプローチに大きく依存する．
そのため，同じ種類のデザインパターンであっても，検出手法ごとに検出箇所が
1
異なる場合もある．このように，デザインパターンの表現方法や着目する特徴な
どが検出手法によって異なるため，抽出すべき特徴を表現できないために検出で
きないデザインパターンや，反対に検出しやすいデザインパターンなどが検出手
法ごとに存在する．つまり，検出手法によってそれぞれのデザインパターンの種
類に対する検出の適性に差があると考えられる．
本研究では，それぞれのデザインパターンの性質や検出アプローチを考慮して，
複数のデザインパターン検出手法を併用することで，個々の検出手法の適性を補
いあうことができるのではないかと考えた．そこで，複数の検出手法を併用する
ことでデザインパターンの検出能力を向上させる手法を提案する．現在，いくつ
かのデザインパターン検出手法をツールとして実装したものが Web 上で公開さ
れている．本研究では，これらのツールの検出結果を組み合わせることで複数検
出手法の併用を実現した．複数検出手法を併用することの妥当性を検証した上で，
複数の併用アルゴリズムの性能評価を行った．
本論文の構成は以下の通りである．2 章では，デザインパターンについて概説
する．3 章では，デザインパターン検出ツールを紹介する．4 章では，本研究で提
案する複数検出手法の併用によるデザインパターン検出について説明する．5 章
では，2 つの実験について報告する．6 章では，実験より得られた知見に関する
考察を述べる．7 章では，既存のデザインパターン検出手法の比較評価，デザイ
ンパターン検出手法の精度改善，デザインパターンの影響分析に関する研究など
について紹介する．最後に，8 章でまとめと今後の課題について述べる．
2
2. デザインパターン
2.1 デザインパターンの概要
近年のソフトウェア開発プロジェクトでは，オブジェクト指向開発が一般的と
なっている．オブジェクト指向開発とは，ソフトウェアの構造をオブジェクト群
の相互作用の関係と捉えて定義していく開発方法論である．オブジェクト指向開
発の利点として，既存のソフトウェアの一部を部品化することによる，再利用性
の向上が挙げられる．既存のソフトウェア部品を再利用することによって，効率
的にソフトウェアの品質を向上させることができる．
しかし，再利用性の高いソフトウェアを設計することは容易ではない．オブジェ
クト指向開発における良い設計とは，現在直面している問題を解決すると同時に，
将来起こり得る問題や要求にも対応できるものでなければならない．また，ソフ
トウェア開発においては熟練した開発者と初心者の生産性に大きな差があるが，
これは経験の差によるものが大きいと一般的に言われている．設計において，熟
練した開発者は自身の経験に基づいたベストプラクティスを繰り返し再利用して
いる．このような再利用の結果として，オブジェクト指向開発において繰り返し
用いられるある種のパターンが生まれることになった．これらのパターンのこと
をデザインパターンという．
デザインパターンは，オブジェクト指向開発において重要でかつ繰り返し発生
する設計を，それぞれ体系的に名前付けし，説明を加え，評価したものである．
最も有名なデザインパターンとしては， Gamma らが提唱した GoF (the Gang
of Four) のデザインパターン [17] が挙げられる．Gamma らは 23 種類のデザイ
ンパターンを文書化してカタログの形でまとめており，一般的にこの 23 種類の
デザインパターンを GoF のデザインパターンと総称している．表 1 に GoF の 23
種類のデザインパターンの一覧を示す．
Gamma らは，23 種類のデザインパターンを 2 つの基準で分類している．1 つ
目の基準は目的で，デザインパターンが何を扱うかを示す．デザインパターンは，
生成，構造，振舞いのうちいずれかの目的を持つ．生成に関するパターンはオブ
ジェクト生成のプロセスを扱う．構造に関するパターンはクラスまたはオブジェ
3
表 1 GoF の 23 種類のデザインパターン
目的
範囲
クラス
生成
構造
振舞い
Factory Method
Adapter
Interpreter
Template Method
オブジェクト
Abstract Factory
Adapter
Chain of Responsibility
Builder
Bridge
Command
Prototype
Composite
Iterator
Singleton
Decorator
Mediator
Facade
Memento
Flyweight
Observer
Proxy
State
Strategy
Visitor
クトの構成を扱う．このクラスとはオブジェクトの雛型を定義したものであり，
オブジェクトとは処理の実体を指す．振舞いに関するパターンはクラスまたはオ
ブジェクトの相互作用の方法を特徴づけ，責任を分担する．2 つ目の基準は範囲
で，デザインパターンがクラスとオブジェクトのどちらに主に適用されるかを示
す．クラスパターンはクラスとサブクラス間の，オブジェクトパターンはオブジェ
クト間の関連をそれぞれ扱う．Adapter パターンは，クラスパターンとオブジェ
クトパターンの両方に属す．
デザインパターンは，ソフトウェアの設計上の問題に対するベストプラクティ
スをまとめたものである．つまり，デザインパターンを利用することで，過去の
成功例を再利用することが容易となり，ソフトウェア設計を効率的に行うことが
できる．また，デザインパターンは開発者同士の共通語彙としても利用すること
ができ，ソフトウェアの設計に際して，互いの意思疎通を円滑にする働きもある．
デザインパターンを習得している開発者同士であれば，パターン名で設計の概
要の合意をとることが可能であるためである．このようなことから，デザインパ
4
ターンを利用することでソフトウェアの品質向上が見込める [17, 42] ため，デザ
インパターンは多くのソフトウェア開発プロジェクトで利用されている．
2.2 デザインパターン検出
デザインパターンはソフトウェア理解においても重要な役割を果たしている
[29, 40]．デザインパターンに含まれる要素（クラス，オブジェクトなど）には
各々の役割が規定されているため，ソフトウェアに適用されているデザインパター
ンを理解することで，要素間の関係や設計段階で想定されていた拡張性などにつ
いて知ることができるからである．デザインパターンに含まれる各要素の役割の
ことをロールという．このように，既存のソフトウェアに適用されているデザイ
ンパターンを検出することで，開発者はソフトウェアの構造に関する理解を深め
ることができ，ソフトウェアの保守が容易になる．
そのため，ソフトウェア理解の支援を目的として，既存のソフトウェアからデ
ザインパターンを検出するための手法がこれまでに数多く提案されている．こう
した検出手法の多くは Gang of Four(GoF) のデザインパターン [17] を検出対象と
しているが，GoF の 23 種類のデザインパターン全てを検出できるわけではなく，
検出手法ごとに検出可能なデザインパターンの種類が異なっている．また，同じ
種類のデザインパターンについても，検出箇所（デザインパターンが適用されて
いると検出された箇所）は，検出手法間で異なっている場合が多い．これらの検
出手法については 3 章で紹介する．
5
3. デザインパターン検出手法
これまでに数多くのデザインパターン検出手法が提案されている．本章では，
こうした検出手法のうち，ツールとして実装されているものを紹介する．表 2 に，
それぞれの検出ツールが検出可能なデザインパターンの種類を示す．この中で，
DPdT は Adapter パターンと Command パターンを区別せずに (Object)AdapterCommand パターンとして検出する．また，State パターンと Strategy パターン
についても State-Strategy パターンとしてそれらを区別せずに検出する．なお，
SPQR は検出可能なデザインパターンの種類が不明であるため，記載を省略して
いる．
また，それぞれの検出手法は検出アプローチ，つまりデザインパターンの定義
やデータ構造，検出アルゴリズムなどが異なっている [10, 5]．表 3 にそれぞれの
検出手法が着目するデザインパターンの特徴を示す．ここでは，デザインパター
ンの特徴を大きく 4 つに分類している．
• 構造 : 主にクラス図から得られるレベルの情報 (継承，関連，集約など)
• 静的な振舞い : 主にソースコード解析から得られるレベルの情報 (メソッド
の呼び出し関係，委譲関係)
• 動的な振舞い : 主に実行時解析から得られるレベルの情報 (イベント列，操
作の開始/終了，オブジェクトの割当て/解放)
• セマンティクス : その他の特別な特徴 (変数値，命名規則)
デザインパターンを実際のソフトウェアに適用する場合には，元々カタログで定
義されていた構造を変形させることもある．このような変形したデザインパター
ンに対する検出能力も，検出アプローチに大きく依存する．表 4 に，変形したデ
ザインパターンに対するそれぞれの検出手法の対応方法を示す．ここでは，対応
方法を大きく 4 つに分類している．
• 未対応 : 変形したデザインパターンへの対応を特にしていない．
6
表 2 検出ツールが検出可能なデザインパターンの種類
ツール名
PRAssistor
検出可能なデザインパターンの種類
Factory Method, Abstract Factory, Builder, Singleton,
Adapter, Bridge, Composite, Decorator, Flyweight, Proxy,
Interpreter, Chain of Responsibility, Iterator, Mediator,
Observer, Strategy, Visitor
DPdT
Factory Method, Prototype, Singleton, Composite,
Decorator, Proxy, Template Method, Observer, Visitor,
(Object)Adapter-Command, State-Strategy
DP-Miner
Adapter, Bridge, Composite, Strategy
PINOT
Factory Method, Abstract Factory, Builder, Singleton,
Adapter, Bridge, Composite, Decorator, Facade, Flyweight,
Proxy, Template Method, Chain of Responsibility, Mediator,
Mediator, Observer, State, Strategy, Visitor
DPRE
Adapter, Bridge, Composite, Decorator, Facade, Proxy,
WOP
Abstract Factory, Builder, Singleton, Adapter, Bridge,
Composite, Proxy, Template Method
PTIDEJ
Factory Method, Composite, Facade, Proxy,
Chain of Responsibility, Memento, Observer, Visitor
FUJABA
Bridge, Composite, Strategy
CrocoPat
Composite
HEDGEHOG
Factory Method, Singleton, Bridge, Proxy, Command
Columbus
Adapter, Strategy
DPVK
Factory Method, Abstract Factory, Builder, Adapter, Bridge,
Composite, Decorator, Flyweight, Proxy, Interpreter,
Command, Iterator, Mediator, Memento, Observer, State,
Strategy, Visitor
Pat
Adapter, Bridge, Composite, Decorator, Proxy
SPOOL
Factory Method, Bridge, Template Method
7
表 3 検出ツールが着目するデザインパターンの特徴
構造
PRAssistor, DPdT, DP-Miner, PINOT, DPRE, WOP,
PTIDEJ, FUJABA, CrocoPat, HEDGEHOG, Columbus,
DPVK, Pat, SPQR, SPOOL
静的な振舞い
PRAssistor, DP-Miner, PINOT, DPRE, FUJABA,
HEDGEHOG, DPVK, SPOOL
動的な振舞い
PRAssitor
セマンティクス
DP-Miner, WOP, HEDGEHOG
表 4 変形したデザインパターンに対する検出手法の対応方法
未対応
PRAssistor, DP-Miner, PINOT, DPRE, WOP,
CrocoPat, Columbus, DPVK, Pat, SPOOL
個別に定義
FUJABA, SPQR
定義で対応
HEDGEHOG
アルゴリズムで対応
DPdT, PTIDEJ
• 個別に定義 : 変形したデザインパターンの構造をケースバイケースに定義
する必要がある．
• 定義で対応 : あらかじめ変形を考慮してデザインパターンの定義を行う．
• アルゴリズムで対応 : あらかじめ変形を考慮して検出アルゴリズムを作成
する．
なお，ここで紹介したツールの中で (1)Java プロジェクトを対象とした，(2)Web
上で公開されているものに関しては，3.16 節でより詳細に説明する．
8
図 1 Pat の検出プロセス [27]
図 2 Adapter パターンの構造 [27] 図 3 Adapter パターンの Prolog ルー
ル [27]
3.1 Pat
Kramer らは，構造に関するパターンを検出する手法を提案している [27]．提
案手法では，システムおよびデザンパターンを Prolog で表現し，Prolog エンジ
ンを用いて検出処理を行う．提案手法の検出プロセスを図 1 に示す．
提案手法では，C++ヘッダファイルからクラス名，属性名，メソッド名，プロ
パティ，および継承や関連，集約といった関係を抽出し，検出処理に用いる．例
えば，図 2 に示す Adapter パターンの Prolog ルールは図 3 のようになる．
上記の提案手法を実装したツールが Pat である．
3.2 HEDGEHOG
Blewitt らは，デザインパターンの仕様を形式的に記述する言語を開発し，そ
れを用いた検出手法を提案している [3]．Blewitt らは，これまでに提案されてき
たデザインパターンが形式化されていない理由を以下のように述べている．
9
• デザインパターンの実装は言語ごとに特有である．
• 同じ言語であっても，デザインパターンの実装方法は多様である．
• オブジェクト指向開発コミュニティにおいて，形式言語記述が一般的では
ない．
提案手法では，対象とする言語ごとに各デザインパターンの具体的な仕様を定
義する．対象の言語を Java として提案手法を実装したツールが HEDGEHOG で
ある．本ツールは，与えられたクラスセットにデザインパターンインスタンスが
正しく実装されているかを確認する目的で使用する．
Blewitt らは，デザインパターンの仕様を定義するために，一階論理によるパ
ターン記述言語 SPINE を開発した．SPINE では，デザインパターンの仕様を，ク
ラス間またはクラス内のメソッド間の関係に関する制約の集合とみなしている．
Blewitt らは，そのような制約を以下のように分類した．
• Structural constraints : 継承や多態インタフェースを通して，各クラス
が互いにどのように関連しているか．
• Static Semantic constraints : 一対一または一対多の関係において，各
クラスが互いにどのように関連しているか．また，それらは必須なのか任
意なのか．
• Dynamic Semantic constraints : あるメソッドが動作することで，どの
ような結果がもたらされるのか．
HEDGEHOG では， Structural constraints と一部の Static Semantic constraints を考慮してデザインパターン検出を行っている．
例えば，Proxy パターンは以下のように定義される．
• クラス C はインタフェース I を実装する (Structural constraint)．
• クラス C は I 型のインスタンス変数 V をもつ (Structural constraint)．
• V は null でない (Semantic consraint)．
10
図 4 デザインパターンのメタモデル [1]
• I の各メソッド M について，C.M は V.M を呼び出す (Semantic constraint)．
ただし，デザインパターンの実装方法は多様であるため，形式化にあたっては
そういった多様性を許容できる記述方法が必要となる．例えば，クラス C が Proxy
であることを示すためには，C が InterfaceProxy か SubclassProxy を実装してい
ることを示せば十分である．
3.3 PTIDEJ
Albin-Amiot らは，変形したデザインパターンでも検出でき，さらにリファク
タリングまで支援する手法を提案している [1]．一般に，デザインパターンはコン
テキストに依存しない抽象モデルで表現されている．提案手法では，デザインパ
ターンをソースコードで記述する際，抽象モデルからいくつかの関係が欠落する
ことを変形とみなす．提案手法におけるデザインパターンのメタモデルの一部を
図 4 に示す．
提案手法では，変形したデザインパターンを検出した場合は両者の差異を計算
し，差異を減少させるための訂正を提案する．変形した Composite パターンに提
案手法を適用した例を図 5 に示す．
Albin-Amiot らは，デザインパターンの検出処理をモデリングするために CSP
11
図 5 変形した Composite パターンの訂正例 [1]
(Constraint Satisfaction Problem) を開発した．CSP は以下の 3 つのパートで構
成されている．
• 変数の集合．与えられたデザインパターンの抽象モデルに含まれる各エン
ティティに対応する．
• 変数間の制約．与えられたデザインパターンの抽象モデルに含まれる各エ
ンティティ間の関係に対応する．
• 変数のドメイン．与えられたソースコードのエンティティおよびそれらの
関係に対応する．
例えば，Composite パターンは以下のように定義される．
• Composite パターンに関わるエンティティは (Component, Composite, Leaf)
である．
• 各変数間の制約は次の通りである．
– composite < component
– leaf < component
– composite ⊃ component.
変形したデザインパターンを検出するために，既存の検出手法では，考えられ
る変形をデザインパターンの定義として新しく追加していた．しかし，この方法で
12
図 6 SPOOL のアーキテクチャ[25]
は新しいデザインパターンの追加や既存のデザインパターンの修正などの際，メ
ンテナンスが非常に困難となる．提案手法では，検出アルゴリズムに explanation-
based constraint programming[24] を用いることで，変形していると疑わしいデ
ザインパターンの候補も検出することができる．そのため，デザインパターンの
変形に対する新たな定義といったメンテナンスは不要となっている．
Java プログラムを対象として提案手法を実装したツールが PTIDEJ(Pattern
Trace Identification, Detection, and Enhancement for Java) である [33]．
3.4 SPOOL
Keller らは，デザインパターンを用いたリバースエンジニアリング環境を提案
している [25]．提案手法のアーキテクチャを図 6 に示す．
提案手法では，ソフトウェアの構成要素ごとにデータ型や他の構成要素との関
係のような構造に関する情報を抽出する (図 7 ).
C++プログラムを対象として提案手法を実装したツールが SPOOL(Spreading
Desirable Properties into the Design of Object-Oriented, Large-Scale Software
Systems) である．
13
図 7 SPOOL で扱う情報 [25]
3.5 FUJABA
Niere らは，ソフトウェアの規模に対するスケーラビリティ問題を改善する検
出手法を提案している [29]．多くのデザインパターンは実装方法が多様であるた
め，あらゆる形のデザインパターンを定義および検出することはほぼ不可能であ
る．既存の検出手法の多くは，呼出しグラフや命名規則などに着目し，多様性に
影響されない粗い検出を行っているが，大量の False Positive が発生してしまう．
一方，データフローグラフやコントロールフローグラフなどに着目し，詳細な検
出を行う検出手法は，大規模なソフトウェアに適用する際，スケーラビリティの
問題によって検出を失敗する．
提案手法では，デザインパターンを ASG(Abstract Syntax Graph) にアノテー
ションを付与する形で表現する．例えば，Composite パターンは図 8 のように定
14
図 8 Composite パターンの定義 [29]
義される．
この定義では，同じ 2 クラス間に 1 つの生成と 1 つの関連が存在すること，お
よびそれらのクラスの 2 操作間に Delegation パターンが存在することを示してい
る．また，これは Leaf クラスを考慮しない場合の Composite パターンを示した
ものであり，その他のバリエーションは個別に定義される．
提案手法では，スケーラビリティの問題を解決するために最適な分析アルゴリ
ズムを開発した．デザインパターン検出の処理は，与えたルールセットを繰り返
しソースコードに適用することで特徴を発見する演繹分析問題とみなすことがで
きる．しかし，純粋な演繹分析アルゴリズムはボトムアップにルールを適用して
いくため，スケーラビリティの問題がある．そこで提案手法では，あるコンテキ
スト (通常，グラフ中の 1 つのオブジェクト) にのみ与えられたルールを適用する
ことで，スケーラビリティの問題を改善している．
Java プログラムを対象として提案手法を実装したツールが FUJABA(From UML
to Java And Back Again) である [13]．
15
3.6 CrocoPat
Beyer らは，ソフトウェアシステムに含まれる様々な関係を容易に問い合わせ
ることができる手法を提案している [2]．Beyer らは，リバースエンジニアリング
における関係問い合わせの応用例として以下のものを挙げている．
• オブジェクト指向ソフトウェアの理解およびドキュメント化を目的とした
デザインパターン検出．
• 設計品質の評価および改善を目的とした問題ある設計パターンの検出．
• ソースコードからのシナリオモデルの抽出を目的としたグラフパターンマッ
チング．
• コードクローン検出およびデザインパターンの帰納推論を目的とした反復
サブグラフの検出．
• デッドコード検出および変更影響分析を目的とした呼出しまたは継承のト
ラバーサル．
• ソフトウェアの理解および修正の支援を目的とした設計-実装間のアーキテ
クチャの不一致の検出．
• 抽象化レベルの異なる複数のビューの生成．
Beyer らは，関係問い合わせのためのデータベース，クエリ言語，データ構造
を開発した．データベースでは，プレーンテキストで関係の読み書きが可能な
RSF(Rigi Standard Format) を利用している．RSF は，関係する 2 つのエンティ
ティおよびその関係名を記述することで，2 項関係を表現する．
クエリ言語では一階述語論理を利用している．例えば，Composite パターンは
以下のように定義される．
CompP at(Component, Composite, Leaf ) :=
IN HERIT (Composite, Component)
∧CON T AIN (Composite, Component)
16
図 9 SPQR の検出プロセス [36]
∧IN HERIT (Leaf, Component)
∧!CON T AIN (Leaf, COmponent);
データ構造としては，膨大な関係を効率的に表現できる BDD(Binary Decision
Diagram) を利用している．
上記の提案手法を実装したツールが CrocoPat である [4]．CrocoPat には入力
として，SNiFF+[39] などを用いてソースコードから生成した RSF ファイルを与
える．
3.7 SPQR
Smith らは，σ-calculus を用いた検出手法を提案している [36]．提案手法の検出
プロセスを図 9 に示す．
σ-calculus はオブジェクト指向言語を形式化した計算モデルであり，提案手法
では，型定義やオブジェクトの型宣言，継承関係などを表現するために用いる．
σ-calculus を ρ-calculus を形成するように拡張し，クラスやオブジェクト間の関
係を表現することも可能となっている．また，検出処理では，デザインパターン
17
図
11
RedirectInFamily の σ-
図 10 RedirectInFamily パターンの calculus 表現 [36]
構造 [36]
でよく使われる要素をさらにパターン化した EDP(Elemental Design Pattern) を
用いている．
例えば，EDP の一つである RedirectInFamily パターン (図 10) の σ-calculus 表
現は図 11 のようになる．
また，考え得るデザインパターンの変形に関しては，あらかじめルールを作成
しておくことで検出することができる．C++プログラムを対象として提案手法を
実装したツールが SPQR(System for Pattern Query and Recognition) である．
3.8 Columbus
Ferenc らは，機械学習を用いた検出手法を提案している [12]．Columbus は C++
プログラムを ASG で表現して，デザインパターンの構造を検出するリバースエ
ンジニアリングツールである．デザインパターンの構造は，XML ベースで開発
した DPML(Design Pattern Markup Language) で記述されており，検出処理は
両グラフの照合によって行われる．しかし，構造にしか着目しないため，State
パターンと Strategy パターンのように構造が似たデザインパターンを弁別できな
い．そこで Ferenc らは，デザインパターンの構造以外の特徴を学習するシステム
を組み込むことで，検出処理の改善を図った．
学習フェーズでは，プログラムの ASG から検出した各候補に相当するソース
コードに対して，正誤を手作業で調査する．その正誤表を教師データとして機械
18
図 12 DPVK の検出プロセス [38]
学習アルゴリズムを適用し，あらかじめ決めておいた各デザインパターンの特徴
パラメータを調整する．
検出フェーズでは，学習済みのパラメータを用いて，プログラムの ASG から
得られた候補に対するフィルタリングを行う．
3.9 DPVK
Wang らは，Eiffel プログラムにおけるデザインパターン検出手法を提案してい
る [38]．提案手法のアーキテクチャを図 12 に示す．
提案手法では，デザインパターンの構造を REQL スクリプトで定義している．
REQL スクリプトによる構造分析でターゲットを絞ったうえで，振舞いに関する
分析を行う．例えば，Composite パターンの構造の定義は図 13，振舞いの定義は
図 14 のようになる．
提案手法では，構造分析ではクラス間の継承および関連の関係に，振舞い分
析では呼出し関係に着目している．提案手法を実装したツールが DPVK(Design
Pattern Veirification toolKit) である．
19
図 14 Command パターンの動的な
図 13 REQL スクリプトによる Com- 定義 [38]
mand パターンの静的な定義 [38]
3.10 DPRE
Lucia らは，ビジュアル言語解析を利用した検出手法を提案している [5]．提案
手法では，まずビジュアル言語解析を行ってターゲットを絞ったうえで，詳細な
ソースコード解析を行う．提案手法の検出プロセスを図 15 に示す．
ビジュアル言語解析においては，クラス図から得られるようなデザインパター
ンの構造に関する情報を扱う．例えば，Adapter パターンの構造に関する情報は
図 16 のように定義され，ビジュアル言語で表現すると図 17 のようになる．
ソースコード解析においては，メソッドの宣言や呼出しに関する情報を扱う．
具体的には，クラス間の継承関係や委譲関係を分析する．
Java および C++プログラムを対象として提案手法を実装したツールが DPRE
(Design Pattern Recovery Environment) である [7]．
3.11 PRAssistor
Huang らは，構造および振舞いの解析による検出手法を提案している [19]. 構
造に関しては，要素情報および関係情報を扱っている．要素情報にはクラス，イ
ンタフェース，属性，操作，コンストラクタが，関係情報には依存，汎化，関連，
生成がそれぞれ含まれる．振舞いに関しては，実行時のインスタンス情報，イベ
ント情報，およびメッセージ情報を扱っている．イベント情報には操作の開始・
20
図 15 DPRE の検出プロセス [5]
図 17
ビジュアル言語における
図 16 Adapter パターンにおけるク Adapter パターンの定義 [5]
ラス間の関係 [5]
21
図 18 Visitor パターンの構造 [19]
図 19 Visitor パターンの Prolog ルー
ル [19]
終了やオブジェクトの割当て・解放が，メッセージ情報には呼出しや送返信，生
成・破棄が含まれる．
提案手法では，デザインパターンの振舞いの時系列を表現するために，Prorlog
に時間の概念を拡張した Temporal Prolog[20] を用いている．例えば，図 18 に示
す Visitor パターンの Prolog ルールは図 19 のようになる．
Java プログラムを対象として提案手法を実装したツールが PRAssistor である．
PRAssistor のアーキテクチャを図 20 に示す．
クラスの構造やクラス間の関係を取得するためにリフレクションを利用してい
る．実行時の振舞いに関する情報の取得には JVMPI(Java Virtual Machine Prifile
Interface)[37] を用いている．
検出処理は，まず構造分析を行ってターゲットを絞ったうえで振舞い分析を行う．
3.12 DPdT
Tsantalis らは，グラフの類似度計算を用いた検出手法を提案している [40]．
Tsantalis らは，既存のデザインパターン検出手法の多くに以下の問題があること
を指摘している．
22
図 20 PRAssistor のアーキテクチャ[19]
• 変形したデザインパターンの検出が困難である．
• システムの規模に対するスケーラビリティに問題がある．
• 新しいデザインパターンの追加が困難である．
Tsantalis らは，グラフアルゴリズムを用いることでこれらの問題を解決した．
提案手法では，システムおよびデザインパターンの構造をグラフで表現する．
具体的には，関連，汎化，抽象クラス，オブジェクト生成，抽象メソッド呼出しな
どの静的な構造を個々にマトリクスで表現する．例えば，図 21 に示す Decorator
パターンのマトリクス表現は図 22 のようになる．
検出処理では，システムおよびデザインパターンの各マトリクスの類似度を算
出し，閾値を用いて成否を判断する．提案手法では，特性の高々1 種類が変形し
ているデザインパターンなら検出することができる．また，検出処理が個々にデ
ザインパターンに依存しないため，新しいデザインパターンを追加する場合は，
必要なマトリクスを作成すれば容易に行うことができる．
提案手法では，グラフサイズの抑制のため，システムをクラスの継承関係で分
割し，そのサブシステム毎にアルゴリズムを適用する．このため，サブシステム
外に拡張したデザインパターンインスタンスは検出することができない．また，
False Positive の抑制のために，デザインパターンを強く特徴づけるロールのみを
検出対象としている．
23
図 21
Decaorator パターンの構造
[40]
図 22
ビジュアル言語における
Adapter パターンの定義 [40]
24
Java プログラムを対象として提案手法を実装したツールを DPdT(Design Pattern detection Tool) と呼ぶ [6]．
3.13 PINOT
Shi らは，GoF のデザインパターンをリバースエンジニリングに適した形に再
分類し，それを用いた検出手法を提案している [35]．通常，GoF のデザインパター
ンは，目的 (生成，構造，振舞い) および対象 (クラス，オブジェクト) という観
点から分類される．しかし，構造に関するデザインパターンでも振舞い分析が必
要であったり，振舞いに関するパターンであっても構造分析で十分である場合が
あるため，従来の分類はリバースエンジニアリングの目的に沿わない．Shi らは
構造と振舞いの類似性に着目して，GoF のデザインパターンを 5 種類に分類した
(図 23)．
1. Language-provided : 言語やパッケージの中で既に定義されている．
2. Structure-driven : 構造設計によって定義され，静的な構造分析で検出で
きる．
3. Behavior-driven : 振舞い設計によって定義され，静的な振舞い分析で検
出できる．
4. Domain-specific : 他のデザインパターンを組み合わせ，特定のドメイン
に特化させる．
5. Generic-concepts :構造や振舞いに関する明確な定義がない．
提案手法では，Structure-driven および Behavior-driven に分類されるデザイン
パターンを検出対象とする．Sturucture-driven パターンに対しては，デザインパ
ターンごとにクラス間の関係を分析する．Behavior-driven パターンに対しては，
構造分析であらかじめターゲットを絞ったうえで，AST を用いたコントロールフ
ロー分析を行う．
25
図 23 GoF のデザインパターンの再分類 [35]
図 24 DP-Miner のアーキテクチャ[9]
Java プログラムを対象として提案手法を実装したツールが PINOT(Pattern INference recOvery Tool) である [32]．PINOT はオープンソースの Java コンパイラ
である Jikes[22] にデザインパターン検出エンジンを組み込む形で実装されている．
3.14 DP-Miner
Dong らは，デザインパターンの構造をマトリクスで表現し，それを用いた検
出手法を提案している [9]．提案手法では構造だけでなく振る舞いやセマンティク
スにも着目して分析を行う．また，プログラムを分析する際，ソースコードを直
接扱うのではなく，それらのクラス図から生成した XMI ファイルを用いる．提
案手法のアーキテクチャを図 24 に示す．
マトリクスでは行と列にクラスをとり，全ての 2 クラス間の関係を表現する．
システムおよび各デザインパターンに対して，個々にマトリクスを作成する．マ
26
表 5 構造要素の素数表現 [9]
構造要素
素数表現
属性
2
メソッド
3
関連
5
汎化
7
依存
11
集約
13
表 6 Adapter パターンのマトリクス
[9]
Class
図 25 Adapter パターン [9]
Target Adapter Adaptee
Target
1
1
1
Adapter
7
1
5
Adaptee
1
1
1
トリクス作成においては，クラスの特性を素数で表現 (表 5) し，複数の特性をも
つクラスのセルの重みはそれらの積となる．ただし，依存と集約は XMI ファイ
ルから読み取ることはできない．依存は振舞い分析で扱い，集約は関連と弁別で
きないので扱わないこととする．
例えば，図 25 に示す Adapter パターンのマトリクス表現は表 6 のようになる．
ただし，表 6 のマトリクスは重みのオーバーフローを避けるため，検出に不要な
構造要素の省略といった最適化を行ったものである．
検出処理では，検出したいクラスの重みと等しいかその値を公倍数にもつクラ
スを探せばよい．振舞い分析では，クラス間の依存や委譲関係を調べる．デザイ
ンパターンの変形に伴う振舞いの多様化には，CFG を用いて振舞いを抽象化す
ることで対応している．また，セマンティクス分析としてはクラスや属性，操作
の命名規則を調べている．
27
Java プログラムを対象として提案手法を実装したツールが DP-Miner である
[11]．
3.15 WOP
Dietrich らは，OWL(Web Ontology Language) によってデザインパターンを形
式的に定義し，それを用いた検出手法を提案している [8]．同じ名前のデザインパ
ターンであっても，コミュニティによって定義が異なる場合があり，異なるコミュ
ニティに属する開発者同士のコミュニケーションに齟齬が生じる恐れがある．こ
の問題は，デザインパターンのコンテキストに関する情報を明示することで容易
に回避することができる．Dietrich らは，そうした情報も含めてデザインパター
ンを形式的に定義することのできる言語として OWL に着目した．
• 形式化でき，機械処理可能であるパターン定義言語．
• 用語を容易に共有できる分散知識表現．
• スキーマとインスタンスを分離できるモジュール設計．
• デザインパターンの記述についての推論ができるメタデータアノテーション．
• 標準 Web 技術と互換性のあるフォーマット．
提案手法では，リフレクション API および命名パターンの分析から得られた
事実に基づいた推論によって検出処理を行う．リフレクション API は，プログラ
ムの実行時にオブジェクト間の関係を検出する働きがあり，プログラムの構造に
関する情報を収集することができる．命名パターン分析とは，例えば， add <
ListenerType > ( < ListenerType > ) や add < ListenerType > ( < ListenerType
> ) といったメソッドを定義しているクラスは， ListenerType クラスとの間に
多くの関連があるだろうとみなすようなことである．
Dietrich らは，個々のデザインパターンに加えて，複数のデザインパターンが
要素を共有する場合についても形式的な定義を行っている．また，検出処理は
exact matching のみを行っている．提案手法を実装したツールが WOP(Web Of
Patterns) である [43]．
28
表 7 既存のデザインパターン検出ツール
ツール名
作者
対象言語
入力ファイル形式
CrocoPat
Beyer ら [2]
Java
RSF ファイル
DPdT
Tsantalis ら [40]
Java
クラスファイル
DP-Miner
Dong ら [9]
Java
XMI ファイル
DPRE
De Lucia ら [5]
C++, Java
ソースコード
FUJABA
Niere ら [29]
Java
ソースコード
PINOT
Shi ら [35]
Java
ソースコード
PTIDEJ
Albin-Amiot ら [1]
Java
ソースコード
WOP
Dietrich ら [8]
Java
ソースコード，クラスファイル
3.16 Web 上で公開されているデザインパターン検出ツール
ここでは，これまで紹介してきたデザインパターン検出ツールのうち，(1)Java
プロジェクトを対象とした，(2)Web 上で公開されているものについて述べる．表
7 に上記の要件を満たすデザインパターン検出ツールを示す．
DPdT は jar ファイルとして配布されている．クラスファイルを入力として，検
出結果は XML ファイル形式で出力される．DPdT のスクリーンショットを図 26
に示す．
DPRE はバッチファイルとして配布されている．java ファイルを入力として，
検出結果は HTML ファイル形式で出力される．DPRE のスクリーンショットを図
27 に示す．
PINOT は Jikes 上で動作するため，コマンドライン経由で操作する．java ファ
イルを入力として，検出結果はテキストファイル形式で出力される．PINOT の
スクリーンショットを図 28 に示す．
WOP は Eclipse のプラグインとして配布されている．java ファイルおよびクラ
スファイルを入力として，検出結果は XML ファイル形式で出力される．WOP の
スクリーンショットを図 29 に示す．
29
図 26 DPdT のスクリーンショット
図 27 DPRE のスクリーンショット
30
図 28 PINOT のスクリーンショット
図 29 WOP のスクリーンショット
31
4. 提案手法
4.1 複数検出手法の併用によるデザインパターン検出
2.2 節でも述べたように，デザインパターンはソフトウェア理解において重要な
役割を果たしている [29, 40]．そのため，ソフトウェア理解の支援を目的として，
既存のソフトウェアからデザインパターンを検出するための手法がこれまでに数
多く提案されている．しかし，検出手法ごとに検出可能なデザインパターンの種
類や検出箇所が異なっている．こうした違いは，検出手法ごとに検出アプローチ
が異なることに起因するものである [10, 5]．そのため，検出手法ごとにそれぞれ
のデザインパターンの種類に対する検出の適性に差があると考えられる．
本研究では，それぞれのデザインパターンの性質や検出アプローチを考慮して，
複数のデザインパターン検出手法を併用することで，個々の検出手法の適性を補
いあい，検出能力を向上させることができるのではないかと考えた．本研究にお
ける「検出能力の向上」とは，具体的には「検出精度の向上」と「検出可能なデ
ザインパターンの種類の増加」の 2 つの意味がある．先に述べたように，デザイ
ンパターン検出手法はそれぞれ検出可能なデザインパターンの種類が異なる．複
数の検出手法を併用し，個々の検出手法が検出対象としないデザインパターンを
補完し合うことで，より多くの種類のデザインパターンを検出することが可能と
なる．また，複数の検出箇所を比較検討することで，検出漏れや誤検出を減らし，
検出精度の向上が期待できる．
そこで，本研究では複数の検出手法を併用することでデザインパターンの検出
能力を向上させる手法を提案する．現在，いくつかのデザインパターン検出手法
をツールとして実装したものが Web 上で公開されている．本研究では，これらの
ツールの検出結果を組み合わせることで複数検出手法の併用を実現した．提案手
法の処理の流れを図 30 に示す．まず，対象のソフトウェアに対し個々の検出ツー
ルを適用して検出結果を得る．次にこの検出結果を組み合わせるため，それぞれ
の形式を加工して検出範囲の統一を行う．最後に検出範囲の統一が済んだ検出結
果を併用アルゴリズムを用いて組み合わせ，その出力をデザインパターン検出の
最終的な検出結果とする．
32
図 30 提案手法の流れ
4.2 検出範囲の統一
複数のデザインパターン検出ツールの検出結果を組み合わせるにあたって，検
出範囲を考慮する必要がある．検出範囲とは，検出箇所と指摘されたデザインパ
ターンに含まれるロールの範囲を指す．同じ種類のデザインパターンであっても，
検出ツールごとに検出箇所とみなすロールの範囲が異なる場合がある．また，検
出ツールによっては，特定の種類のデザインパターンの検出箇所が膨大な件数に
なり，比較が困難となる．
このようなことから，検出ツール間の検出結果を比較するためには，検出範囲
を統一しなければならない．本研究では，各デザインパターンに関して全ての検
出ツールに共通する検出範囲に統一し，それ以外のロールは考慮しないこととし
た．統一した検出範囲の一覧を表 8 に示す．個々の検出ツールの検出範囲につい
ては付録 A に示す．なお，DPdT は Adapter パターンと Command パターンを区
別せずに (Object)Adapter-Command パターンとして検出する．また，State パ
ターンと Strategy パターンについても State-Strategy パターンとしてそれらを区
別せずに検出する．
4.3 併用アルゴリズム
本研究では，5.1.1 節で述べたような妥当性を検証した上で，複数のデザイン
パターン検出手法を併用するアルゴリズムとしてどのようなものが有用なのか調
33
表 8 統一した検出範囲
デザインパターン名
ロール名
Abstract Factory
Abstract Factory, Abstract Product
Factory Method
Factory Method
Prototype
Prototype
Singleton
Singleton
Adapter
Adapter, Adaptee
Bridge
Abstraction, Implementor
Composite
Composite, Component
Decorator
Decorator, Component
Facade
Facade
Flyweight
Flyweight Factory
Proxy
Proxy
Chain of Responsibility Chain of Resposibility
Command
Command, Receiver
Mediator
Mediator
Observer
Observer
State
State, Context
Strategy
Strategy, Context
Template Method
Template Method
Visitor
Visitor
34
べた．複数の検出手法を併用するというアプローチはこれまでに研究されていな
いため，どの要因が併用結果にどのような影響を与えるかということはわかって
いない．そこで，今回はクラスおよびクラス集合に対する検出箇所の重複に着目
し，併用アルゴリズムを考案した．ここでは，今回性能評価を行った 3 種類の併
用アルゴリズムについて紹介する．
4.3.1 和集合
和集合は，それぞれの検出ツールの全ての検出箇所を採用する併用アルゴリズ
ムである．その性質上，検出結果の再現率があらゆる併用アルゴリズム中で最大
になるという利点がある．ソフトウェア理解においては，ソフトウェアの特徴を
見落とさないために，デザインパターン検出の再現率は高いことが望ましい [18]．
また，5.1.1 節の妥当性を検証するために行った実験では，併用アルゴリズムとし
て和集合を用いている．
4.3.2 多数決
コンピュータ将棋の分野で，
「合議アルゴリズム」という新しい考え方が生まれ
ている [45]．個性の異なる複数のプログラムに同じ局面を与え，それぞれのプロ
グラムが出力した候補手の中から合議によって一手を決めるという方法である．
小幡らは単純な多数決によって 4 プログラムの合議を行い，単体プログラムに有
意に勝ち越す結果を出している．
本研究では，合議アルゴリズムの考え方が検出ツールの併用アルゴリズムに応
用できると考えた．ソフトウェア中の各クラスについて，複数のデザインパター
ン検出箇所として指摘されることは多々ある．そこで，そのクラスが含まれるデ
ザインパターンの種類に関する多数決を行った．
4.3.3 適性値付き和集合
4.3.2 で述べたことと同様に，同じクラス集合について複数のデザインパター
ン検出箇所として指摘される場合は多々ある．これは，デザインパターンの中に
35
は State パターンと Strategy パターンのように構造が似ているものがあり，この
ために誤検出が発生しているものと考えられる．また，4.2 節でも述べたように，
検出結果を組み合わせるために検出範囲を統一していることにも原因があると考
えられる．このような検出箇所の重複が誤りであるのか，それともそのクラス集
合に本当にデザインパターンが集中しているのかを，適切に区別することは検出
能力の向上に有用である．
本研究では，検出箇所の重複における誤りを減らすために，検出ツールのデザ
インパターンに対する検出適性をパラメータとして導入した．異なる種類のデザ
インパターンの構造が似ているために検出箇所の重複が発生するのであれば，よ
り適性値の高い検出ツールのほうを採用することで，誤検出を減らせると考えら
れる．検出適性の判断材料としては，図 23 に示す Shi らの分類を利用した．検
出ツールが Shi らの各 5 分類に含まれるデザインパターンの種類を多く検出対象
にしているほど，その分類に含まれるデザインパターンに対する検出適性は高い
とみなしている．この検出ツールの各分類に対する適性値は以下のように算出で
きる．
適性値 =
分類に含まれ，かつ検出対象であるデザインパターンの種類の数
分類に含まれるデザインパターンの種類の総数
このアルゴリズムでは，重複がない場合は 4.3.1 で紹介した和集合と同じ方法
をとる．検出結果の重複が起きた場合のみ，適性値の高い検出ツールのみを採用
することで誤検出を減らせると考えられる．
36
5. 実験
本研究では，大きく分けて 2 種類の実験を行っている．1 つ目は，複数のデザ
インパターン検出手法を併用することで検出能力が向上するという本研究の妥当
性を確認するために行った実験である．2 つ目は 4.3 節で紹介した併用アルゴリ
ズムの性能を評価するために行った実験である．前者は 5.1 節で，後者は 5.2 節
でそれぞれ説明する．
5.1 妥当性の検証
本節では，本研究の妥当性を確認するために行った実験について説明する．以
降，5.1.1 では本研究の妥当性を確認するために検証すべき 2 つの仮説について説
明する．5.1.2 で実験で利用したデザインパターン検出ツールと，検出対象とした
プロジェクトについて説明する．5.1.3 では検出ツールによってどのようなデザイ
ンパターンが検出されるかを確認する（後述する仮説 1 の検証）．5.1.4 ではデザ
インパターン検出結果を組み合わせることで，検出能力がどの程度向上するかを
確認する（後述する仮説 2 の検証）．
5.1.1 妥当性を検証する仮説
3 章で示したように，それぞれのデザインパターン検出手法ごとに，その検出
アプローチは大きく異なっており，検出可能なデザインパターンの種類も異なる．
また，検出アプローチや検出対象のデザインパターンの構造によって，検出箇所
にも大きく差があると考えられる．このように，検出手法ごとに，検出可能なデ
ザインパターンの種類や検出箇所が大きく異なるのであれば，複数の検出手法を
適切に併用することで，検出能力の向上が期待される．本研究では，複数検出手
法を併用する具体策として，デザインパターン検出ツールの検出結果を組み合わ
せる方法をとっている．そこで，検出能力の向上を目的とした検出結果の組み合
わせを検討するにあたって，まず以下の仮説を検証する．
(仮説 1) デザインパターン検出手法によって，検出可能なデザインパターンの
種類や，デザインパターンの検出箇所が異なる．
37
仮説 1 が成立すれば，複数の検出手法を併用することによる，検出能力の向上
が期待できる．そこで，仮説 1 を確認した上で，以下の仮説を検証する．
(仮説 2) 複数のデザインパターン検出手法を併用することにより，デザインパ
ターン検出能力を向上することができる．
本研究における「検出能力の向上」とは，具体的には「検出精度の向上」と「検
出可能なデザインパターンの種類の増加」の 2 つの意味がある．先に述べたよう
に，デザインパターン検出ツールは，それぞれの検出アプローチの違いによって
検出可能なデザインパターンの種類が異なる．複数の検出ツールを併用し，個々の
検出手法が検出対象としないデザインパターンを補完し合うことで，より多くの
種類のデザインパターンを検出することが可能となる．また，複数の検出結果を
比較検討することで，検出漏れや誤検出を減らし，検出精度の向上が期待される．
5.1.2 実験対象
今回は，3.16 節で紹介した検出ツールのうち，本研究の実験環境において使用
可能であった DPdT，DPRE，PINOT，WOP の 4 つを使用した．3.16 節に示し
た通り，これらの検出ツールは全て Java プロジェクトを対象としているが，そ
れぞれの検出アプローチは異なっている．そのため，同じ種類のデザインパター
ンであっても，検出箇所は大きく異なると考えられる．また，表 2 に示した通り，
検出可能なデザインパターンの種類も異なっている．
デザインパターン検出の対象プロジェクトとして Java で書かれたオープンソー
スプロジェクト JHotDraw 5.1 および 6.0 beta 1 [21]， JRefactory 2.6.24 [23]，
Lexi 0.1.1 alpha [28] を利用した．JHotDraw 6.0 beta 1 に関しては， Dong らが
Strategy パターンの手作業による検出箇所のリスト [11] を公開している．また，
JHotDraw 5.1， JRefactory 2.6.24 および Lexi 0.1.1 alpha に関しては Gueheneuc
らの手作業による検出箇所のリストを入手している．これらを検出箇所の正例と
して用いることで，検出ツールの検出精度を比較評価することが可能となる．
38
5.1.3 実験 1: 検出されるデザインパターンの確認
実験方法
本実験では，仮説 1 を検証するために，デザインパターン検出ツール
の検出結果の違いを分析する．5.1.2 で紹介したように，4 つの Java プロジェクト
を対象に 4 つの検出ツールの各デザインパターンの検出件数を調べる．また，4.2
節で述べたように各検出ツールでは検出範囲が異なるが，表 8 に示す統一した検
出範囲に従って検出結果を整理した上で検出件数を数える．そして，検出ツール間
の検出結果がどの程度一致しているのかを分析する．ただし， DPdT は Adapter
パターンと Command パターン，および State パターンと Strategy パターン
を区別せず，それぞれ (Object)Adapter-Command パターン， State-Strategy パ
ターンとして検出する．そこで， (Object)Adapter-Command パターンについて
は Adapter パターンと Command パターン，State-Strategy パターンについて
は State パターンと Strategy パターン，というように，両者とも検出箇所とみ
なすこととする．
実験結果
各検出ツールの検出件数についてまとめた結果を表 9 に示す．それぞ
れの数値は，各検出ツールの検出件数について 4 つのプロジェクトでの合計をとっ
たものである．表中の棒線は，その検出ツールにおいてそのデザインパターンが
検出対象でないことを表している．表より，各デザインパターンの検出件数が検
出ツールによって大きく異なることがわかる．プロジェクトごとの検出件数は付
録 B に示す．
また，検出ツール間の検出箇所の一致件数についてまとめた結果を表 10 に示
す．表の○種類の数字は，検出箇所が一致した件数を表している．それぞれの数
値は，検出ツール間の検出箇所の一致件数について，4 つのプロジェクトにおけ
る全てのデザインパターンでの合計をとったものである．表より，各検出ツール
の検出箇所の多くが一致していないことがわかる．プロジェクトごとの検出箇所
の一致件数は付録 C に示す．
以上の結果より，今回利用した検出ツール間では，仮説 1 が成立することが確
認できた．
39
表 9 各検出ツールの合計検出件数
DPdT
DPRE
PINOT
WOP
-
-
0
46
12
-
28
-
Prototype
8
-
-
-
Singleton
24
-
4
11
Adapter
96
125
14
91
Bridge
-
202
27
55
Composite
3
1
9
18
Decorator
16
0
5
-
Facade
-
39
108
-
Flyweight
-
-
8
-
14
3
41
1
-
-
5
-
96
-
-
-
Mediator
-
-
415
-
Observer
17
-
6
-
State
184
-
3
-
Strategy
184
-
37
-
28
-
0
19
3
-
2
0
Abstract Factory
Factory Method
Proxy
Chain of Responsibility
Command
Template Method
Visitor
表 10 検出ツール間の検出箇所の合計一致件数
1 種類
1672
2 種類 3 種類 4 種類
110
13
40
0
5.1.4 実験 2: 検出手法の組み合わせによる精度の確認
実験方法
本実験では仮説 2 を検証，すなわち複数の検出ツールを併用すること
で検出能力が向上できるかどうかを検証する．4.3.1 で述べたように，この実験で
は複数検出ツールの併用アルゴリズムとして，全ての検出ツールの検出箇所の和
集合をとる．そして，それぞれの検出ツールの検出箇所および検出箇所の和集合
をとったものについて検出精度を算出する．
検出精度の評価にあたっては，5.1.2 で述べたように，JHotDraw 6.0 beta 1
に関しては Dong らが公開している Strategy パターンの検出箇所のリストを，
JHotDraw 5.1， JRefactory， Lexi に関しては Gueheneuc らによる検出箇所の
リストを用いる．これらのデータはそれぞれのプロジェクトを対象に，各デザイ
ンパターンの検出箇所を手作業で評価したものである．このデータをデザインパ
ターン検出の正例として，以降の評価に用いる．
検出精度の評価尺度としては，正しくデザインパターンとして検出できた個
数（True Positive; TP），間違ってデザインパターンとして検出した数（False
Positive; FP），デザインパターンであるのにも関わらず検出できなかった個数
（False Negative; FN）を算出する．そして，これらの値をもとに，正解集合に含
まれるデザインパターンを正しく検出できた割合（再現率）と検出結果の中に含
まれる正解デザインパターンの割合（適合率）を求める．さらに，再現率と適合
率の調和平均である F 値もあわせて求める．
実験結果
各プロジェクトにおける個々の検出ツールおよび和集合による併用結
果の検出精度についてまとめた結果を表 11 に示す．表は各プロジェクトにおけ
る個々の検出ツールおよび和集合による併用結果について，検出箇所の TP(True
Positive)， FN(False Negative)， FP(False Positive) を合計した上で適合率，再
現率，F 値を算出したものを示している．表中の棒線は，その検出ツールにおい
てそのプロジェクトのデザインパターンが検出対象でないことを表している．表
より，JHotDraw 6.0 beta 1 以外のプロジェクトでは，和集合の F 値は個々の検出
ツールと同じかそれを下回っている．これは，個々の検出ツールの False Positive
が多すぎたため，適合率が著しく低下したことに起因する．しかし，ソフトウェ
41
ア理解においては，デザインパターン検出の再現率は高いことが望ましいとされ
ている [18]．再現率に関しては，和集合は全てのプロジェクトにおいて個々の検
出ツールと同じかそれ以上の値となっている．そのため，これらのプロジェクト
についても検出精度が向上したということができる．デザインパターンの種類別
の検出精度を含む詳細な評価結果は付録 D に示す．
以上の結果より，今回の実験では仮説 2 が成立することが確認できた．よって，
5.1.3 の結果とあわせて仮説 1 および仮説 2 が成立することが確認できたので，本
研究の妥当性が確認できたと言える．
5.2 併用アルゴリズムの比較評価
5.1 節では，複数検出手法の併用によってデザインパターン検出能力が向上で
きることを確認した．本節では，検出能力の向上に適した併用アルゴリズムの発
見を目的として，複数の併用アルゴリズムを比較評価した実験について説明する．
5.2.1 実験対象
実験対象の Java プロジェクトおよび検出ツールは 5.1 節と同様である．
3.16 節で紹介した検出ツールのうち，DPdT，DPRE，PINOT，WOP の 4 つ
を使用した．デザインパターン検出の対象プロジェクトとしては，オープンソー
スプロジェクト JHotDraw 5.1 および 6.0 beta 1， JRefactory 2.6.24， Lexi
0.1.1 alpha を利用した．検出箇所の正例としては，JHotDraw 6.0 beta 1 に関し
ては， Dong らが公開している Strategy パターンの手作業による検出箇所のリ
ストを， JHotDraw 5.1， JRefactory 2.6.24 および Lexi 0.1.1 alpha に関しては，
Gueheneuc らの手作業による検出箇所のリストを用いた．
5.2.2 実験方法
本実験では，検出能力の向上に適した併用アルゴリズムを発見するために，複
数の併用アルゴリズムの性能を評価する．今回は 4.3 節で紹介した，和集合，多
42
表 11 各プロジェクトにおける検出ツールごとの検出精度のまとめ
検出ツール
JHotDraw
6.0 beta 1
DPdT
DPRE
PINOT
WOP
和集合
TP/FN/FP
JHotDraw JRefactory
Lexi
5.1
54/11/40 14/190/134
3/19/75
2/9/0
適合率
0.574
0.0946
0.0385
1
再現率
0.831
0.0686
0.136
0.182
F値
0.679
0.0795
0.06
0.308
-/65/-
4/200/36
0/22/34
0/11/0
適合率
-
0.1
0
0
再現率
-
0.0196
0
0
F値
-
0.0328
0
0
9/56/4
0/204/2
0/22/25
1/10/0
適合率
0.692
0
0
1
再現率
0.138
0
0
0.0909
F値
0.231
0
0
0.167
-/65/-
4/200/34
1/21/6
2/9/0
適合率
-
0.105
0.143
1
再現率
-
0.0196
0.0455
0.182
F値
-
0.0331
0.0690
0.308
58/7/44
16/188/187
3/19/121
2/9/0
適合率
0.569
0.0788
0.0242
1
再現率
0.892
0.0784
0.136
0.182
F値
0.695
0.0786
0.0411
0.308
TP/FN/FP
TP/FN/FP
TP/FN/FP
TP/FN/FP
43
数決，適性値付き和集合の 3 種類の併用アルゴリズムについて行った．5.1.4 と同
様に，DPdT, DPRE, PINOT, WOP の 4 つの検出ツールの検出結果を 3 種類の併
用アルゴリズムによってそれぞれ組み合わせる．そして，Dong らや Gueheneuc
らによるデザインパターン検出の正例を用いて精度評価を行い，併用アルゴリズ
ムによる違いを分析する．
5.2.3 実験結果
各プロジェクトにおけるそれぞれの併用アルゴリズムによる併用結果の検出
精度についてまとめた結果を表 12 に示す．表は各プロジェクトにおけるそれぞ
れの併用アルゴリズムによる併用結果について，検出箇所の TP(True Positive)，
FN(False Negative)， FP(False Positive) を合計した上で適合率，再現率，F 値を
算出したものを示している．表より，JRefactory 以外のプロジェクトでは，和集
合の F 値が他の 2 つと同じかそれ以上となっていることがわかる．多数決および
適性値付き和集合では False Positive を減らすことが期待できるが，同時に True
Positive の取りこぼしも発生してしまう．今回の実験では， JRefactory 以外のプ
ロジェクトでは False Positive を減らせたことより True Positive を取りこぼし
たことの方が影響が大きかったと言える．JRefactory では，適性値付き和集合で
除去された検出箇所が全て False Positive であったため，同じ再現率の和集合を
適合率で上回り，結果的に F 値が高くなっている．しかし，この適性値付き和集
合の優位はわずかであるため，3 つの併用アルゴリズムの中では和集合が最も高
性能であるといえる．デザインパターンの種類別の検出精度を含む詳細な評価結
果は付録 E に示す．
44
表 12 各プロジェクトにおける併用アルゴリズムの検出精度のまとめ
検出ツール
和集合
多数決
適性値付き和集合
JHotDraw
JHotDraw JRefactory
Lexi
6.0 beta 1
5.1
58/7/44
16/188/187
3/19/121
2/9/0
適合率
0.569
0.0788
0.0242
1
再現率
0.892
0.0784
0.136
0.182
F値
0.695
0.0786
0.0411
0.308
11/54/8
8/196/66
1/21/70
2/9/0
適合率
0.579
0.108
0.0141
1
再現率
0.169
0.0392
0.0455
0.182
F値
0.262
0.0576
0.0215
0.308
58/7/44
13/191/165
3/19/118
0/11/0
適合率
0.569
0.0730
0.0248
0
再現率
0.892
0.0637
0.136
0
F値
0.695
0.0681
0.0420
0
TP/FN/FP
TP/FN/FP
TP/FN/FP
45
6. 考察
6.1 併用アルゴリズムの性能
5.2 節において，和集合，多数決，適性値付き和集合の 3 種類の併用アルゴリ
ズムの性能比較を行い，和集合が最も高性能であるという知見を得た．また，ソ
フトウェア理解においてはデザインパターン検出の再現率が高いことが望ましい
[18] ため，その意味でも再現率が最大となる和集合は優れていると言える．しか
し，個々の検出ツールで False Positive が大量に発生した場合，それらを全て採
用してしまう和集合では適合率が著しく低下する．そのため， False Positive の
除去は複数検出手法の併用において重要な課題である．
多数決および適性値付き和集合では False Positive の除去を目的とした検出箇
所の絞込みを行っている．実験において，多数決によって大量の False Positive
が除去されるという状況も確認できた．しかし， False Positive と一緒に True
Positive も除去してしまうという問題がある．この問題は程度の差はあれど，適
性値付き和集合についても同様であった．
6.2 検出範囲
本研究では，複数検出手法の併用のために，各デザインパターンに関して検出
範囲を全ての検出ツールに共通する範囲に統一している．これは検出箇所の比較
や精度評価のために行ったことであるが，統一された検出範囲に含まれないロー
ルまで指摘できる検出ツールの検出性能を意図的に低下させているとも言える．
このような状況では検出手法の併用だけでなく，検出手法同士の性能比較なども
困難である．そのため，目的に応じた望ましい検出範囲などについては今後議論
が必要である．具体的には，検出範囲を変えた時の検出精度の変動などを測定す
ることで，最適な検出範囲が得られるのではないかと考えられる．
46
6.3 実験結果の妥当性
本研究においては，5.1.1 節で述べた妥当性の検証，つまりデザインパターン検
出ツールによって検出結果が異なること (仮説 1)，および検出ツールを併用する
ことで検出能力が向上できること (仮説 2) を示した．また，4.3 節で紹介した 3 つ
の併用アルゴリズムのうち，実用上は和集合が最も高性能であることを示した．
ただし，今回使用した検出ツールは本研究の環境で実行可能であった 4 つのみ
である．Web 上で公開されている検出ツールのうち，いくつかは使用できる条件
が合わず，使用を見送っている．また，今回使用した検出ツールはいずれも Java
を主な対象言語としている．C++ や Smalltalk を対象言語とする検出ツールにつ
いては今回は検証していない．実験対象のソフトウェアも 4 つの Java プロジェク
トのみである．本研究の知見が一般的に成りたつのか，検出ツールやソフトウェ
ア，プログラミング言語を変えてさらに検証していくことが必要である．
また，精度評価の正例として Dong らおよび Gueheneuc らの手作業による検出
箇所のリストを用いた．この正例自体にも False Positive や False Negative が存
在する可能性は否定できない．しかし，このようなデザインパターン検出の正例
を入手および作成することは一般に困難である．オープンソースソフトウェアで
は，ソフトウェア中に適用されているデザインパターンの情報を詳細に管理して
いることはほとんどない．そのため，現状では手作業による検出箇所のリストが
最も信頼性の高い正例と言える．
本研究の提案手法は，個々の検出ツールが正常に検出結果を出力することが前
提となっている．そのため，対象ソフトウェアが個々の検出ツールの求める入力
形式を満たしていなければならない．つまり，提案手法を適用するためには，ソ
フトウェアのソースコードやクラスファイルを入手する必要がある．
検出範囲の統一は，使用する全ての検出ツールの検出範囲を考慮して決定して
いる．そのため，使用する検出ツールが増えたり変わったりした場合は，その度
に統一した検出範囲を見直す必要がある．また，個々の検出ツールの検出結果を，
元々の検出範囲から統一した検出範囲に適合させる処理も検出ツールごとに行っ
ている．これについても，使用する検出ツールが増えたり変わったりした場合は，
その度に検出ツールごとに処理方法を見直さなければならない．
47
7. 関連研究
7.1 デザインパターン検出手法の比較評価
これまでに提案されているデザインパターン検出手法は，対象とするプログラ
ミング言語や検出可能なデザインパターンの種類，デザインパターンの検出箇所
など多くの点で異なっている．また，それぞれの検出手法の性能評価の方法が手
法によってまちまちであるため，検出手法間での検出精度などの性能比較が困難
であった．そのため，近年は既存のデザインパターン検出手法の比較評価に関す
る研究が増えている．
Dong らは，既存のデザインパターン検出手法に関する比較研究を行っている
[10]．それぞれの検出手法を，デザインパターンの表現方法や着目する特徴など
様々な観点から分類している．また，同じソフトウェア，同じデザインパターン
に対する検出結果が手法によって異なる原因についての分析も行っている．
Fulop らは，デザインパターン検出ツールを評価するベンチマーク DEEBEE
(DEsign pattern Evaluation BEnchmark Environment) を提案している [15]．DEEBEE はプロジェクト管理ツール Trac[41] を拡張したもので，デザインパターン検
出ツールに関する各種データベースのビューを提供する．また，Fulop らは C++
プロジェクトを対象とするデザインパターン検出ツールの比較評価も行っている
[14]．Columbus[12]， Maisa[30] および CrocoPat[2] の 3 つのツールについて，検
出箇所，処理速度およびメモリ使用量に関して比較している．
Pettersson らは，デザインパターン検出の精度を評価するフレームワークを提
案している [31]．検出手法間の精度比較を妨げるいくつかの問題を指摘し，それ
を解決するための方法について述べている．
7.2 デザインパターン検出手法の精度改善
深谷らは，デザインパターン適用前のソースコード解析を併用することで，デ
ザインパターン検出ツールの検出精度を改善する手法を提案している [44]．深谷
らは，デザインパターン適用前のソースコードには，後にデザインパターンを適
48
用できる箇所があると考え，その部分を識別する情報をデザインパターン検出に
利用している．
7.3 デザインパターンの影響分析
デザインパターンを利用することでソフトウェアの品質向上が見込めると言わ
れている [17, 42] が，それを定量的に示した研究は少ない．ここでは，デザイン
パターンがソフトウェアに与える影響に関する研究を紹介する．
Khomh らは，デザインパターンがソフトウェアの保守工程に与える影響に関す
る研究を行っている [26]．Composite パターン，Abstract Factory パターンおよ
び Flyweight パターンの 3 種類のデザインパターンについて，各デザインパター
ンを利用することで再利用性，可読性および拡張性にどのような影響を与えるか
分析している．筆者らの過去の実験結果を用いて仮説検定を行い，それに対する
考察を行っている．
Fushida らは，デザインパターンの適用履歴に関する分析を行っている [16]．
Fushida らは，デザインパターンがソフトウェアの品質や生産性に与える影響を
知るための手がかりとしてデザインパターンの適用履歴が重要であると考え，そ
の分析方法を提案している．
49
8. まとめ
本研究では，まずソフトウェアの品質を向上させるデザインパターンについて，
最も有名な GoF のパターンを挙げて概要を述べた．また，デザインパターンが
ソフトウェア設計時だけでなく，ソフトウェア理解においても有用であることを
述べた．
次に，ソフトウェア理解の目的でこれまでに数多くのデザインパターン検出手
法が提案されており，それぞれの検出手法で検出アプローチが大きく異なること
を文献調査によって明らかにした．いくつかの検出手法はツールとして実装され
ており，Web 上で公開され一般に使用可能であることを確認した．
次に，複数検出手法を併用することでデザインパターン検出能力が向上できる
ことを示した．本研究の妥当性を検証するために 2 つの仮説を立てて，4 つの Java
プロジェクトと 4 つの検出ツールを用いた実験によってそれらを確認した．複数
検出手法を併用するにあたっての検出範囲の違いという問題を指摘し，それを解
決するために全ての検出ツールに共通する検出範囲に統一する方法を示した．
次に，3 種類の併用アルゴリズムを考案し，それらの比較評価を行った．その
結果，検出ツールの併用方法として全てのツールの検出箇所の和集合をとった場
合，適合率はわずかに低下するが再現率および F 値が改善することが多く，3 種
類の中では最も高性能であることを示した．
今後は，本研究で提案した複数検出手法の併用というアプローチの有用性が認
知され，普及していくことが望まれる．デザインパターン検出手法自体やその比
較評価の方法など，関連分野の研究は今後も盛んに行われていくと考えられる．
また，デザインパターン検出の正例データが増えれば精度評価が行いやすくなる．
使用可能な検出ツールや正例データが増え，分析環境などが今後整ってくれば，
今回の 3 種類の併用アルゴリズムよりも高性能なものも考案できると考えられる．
50
謝辞
本論文は，筆者が奈良先端科学技術大学院大学情報科学研究科ソフトウェア
設計学講座に在籍中の研究成果をまとめたものです．本研究を進めるにあたり，
多くの方々から御指導，御協力を賜りました．ここに記して感謝の意を表す次第
です．
奈良先端科学技術大学院大学情報科学研究科ソフトウェア設計学講座飯田元
教授には，本研究の全過程において熱心な御指導を賜りました．研究方針だけで
はなく，研究に対する姿勢，論文執筆，発表方法についても多くの御助言を賜り
ました．心より厚く御礼申し上げます．
奈良先端科学技術大学院大学情報科学研究科ソフトウェア工学講座松本健
一教授，ならびにソフトウェア基礎学講座安本慶一准教授には，学内の発表
において多数の貴重な御質問，御助言を賜りました．心より感謝申し上げます．
奈良先端科学技術大学院大学情報科学研究科ソフトウェア設計学講座川口真
司助教，ならびに伏田享平氏には，本研究を進めるにあたり，広範囲かつ多大
な御助力を賜りました．特に，筆者が論文投稿直前に新型インフルエンザに感染
した際，親身になって御指導頂きました．心より感謝申し上げます．
株式会社日立製作所名倉正剛氏には，研究方針や発表方法などについて貴
重な御助言を賜りました．心より感謝申し上げます．
Ecole Polytechnique de Montreal の Yann-Gael Gueheneuc 准教授には，本研
究を進めるにあたり，貴重なデータを快く御提供頂きました．心より感謝申し上
げます．
奈良先端科学技術大学院大学情報科学研究科ソフトウェア設計学講座，なら
びにソフトウェア工学講座の皆様には，日頃より多大な御協力と御助言を賜り，
公私ともに支えて頂きました．ありがとうございました．
最後に，日頃より私を励まし，暖かく見守ってくれた家族に心より深く感謝し
ます．
51
参考文献
[1] H. Albin-Amiot, P. Cointe, Y. Gueheneuc, and N. Jussien, “ Instantiating and detecting design patterns: putting bits and pieces together. ” In
Proceedings 16th Annual International Conference on Automated Software
Engineering (ASE), 2001.
[2] Dirk Beyer , Andreas Noack , Claus Lewerentz, Simple and Efficient Relational Querying of Software Structures, Proceedings of the 10th Working
Conference on Reverse Engineering, p.216, November 13-17, 2003.
[3] Blewitt and A. Bundy, “ Automatic verification of Java design patterns. ”
Proceedings of International Conference on Automated Software Engineering, pp. 324-327, 2001.
[4] CrocoPat Homepage.http://www.sosy-lab.org/?dbeyer/CrocoPat/
[5] Andrea De Lucia, Vincenzo Deufemia, Carmine Gravino, Michele Risi, Design pattern recovery through visual language parsing and source code analysis, The Journal of Systems and Software, 2009. (To appear).
[6] Design Pattern Detection Homepage. http://java.uom.gr/$sim$nikos/
pattern-detection.html
[7] Design Pattern Recovery Homepage. http://www.sesa.dmi.unisa.it/
dpr/index.html
[8] J. Dietrich, C. Elgar, ”Towards a Web of Patterns,”Proc. Semantic Web
Enabled Software Engineering(SWESE), 117-132, Galway, Ireland, 2005.
[9] Jing Dong , Dushyant S. Lad , Yajing Zhao, DP-Miner: Design Pattern
Discovery Using Matrix, Proceedings of the 14th Annual IEEE International
Conference and Workshops on the Engineering of Computer-Based Systems,
p.371-380, March 26-29, 2007
52
[10] Jing Dong, Yajing Zhao, and Tu Peng, A Review of Design Pattern Mining
Techniques, the International Journal of Software Engineering and Knowledge Engineering (IJSEKE), World Scientific Publishing, 2009. (To appear).
[11] DP-Miner
Homepage.
http://www.utdallas.edu/∼yxz045100/
DesignPattern/DP Miner/index.html
[12] R. Ferenc, A. Beszedes, L. Fulop, and J. Lele, “ Design pattern mining
enhanced by machine learning. ” In Proceedings of the 21st IEEE International Conference on Software Maintenance (ICSM ’05), 2005.
[13] FUJABA Homepage.http://wwwcs.uni-paderborn.de/cs/fujaba/
[14] L. Fulop, T. Gyovai, and R. Ferenc. Evaluating C++ Design Pattern Miner
Tools. In Proceedings of the 6th International Workshop on Source Code
Analysis and Manipulation (SCAM 2006), pages 127-136. IEEE Computer
Society, Sept. 2006.
[15] L. J. Fulop, R. Ferenc, and T. Gyimothy. Towards a Benchmark for Evaluating Design Pattern Miner Tools. In Proceedings of the 12th European Conference on Software Maintenance and Reengineering (CSMR 2008). IEEE
Computer Society, Apr. 2008.
[16] K. Fushida, S. Kawaguchi, and H. Iida. A method of investigate software
evolutions using design pattern detection tool. In Proceedings of the 1st
International Workshop on Software Patterns and Quality(SPAQu ’07), pp.
11-16, Nagoya, Japan, 2007.
[17] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley, 1st edition,
1994.
[18] Y.-G. Gueheneuc and G. Antoniol. DeMIMA: A multi-layered framework
for design pattern identification. In Transactions on Software Engineering
53
(TSE), 34(5):667-684, September 2008.
[19] Heyuan Huang, Shensheng Zhang, Jian Cao, Yonghong Duan, A practical
pattern recovery approach based on both structural and behavioral analysis,
Journal of Systems and Software, 75(1-2), pp.69-87, February 2005.
[20] Hrycej, T, A temporal extension of Prolog. Journal of Logic Programming
15, 113-145, 2002.
[21] JHotDraw Homepage. http://www.jhotdraw.org/
[22] Jikes Homepage. http://jikes.sourceforge.net/
[23] JRefactory Homepage. http://jrefactory.sourceforge.net/
[24] N. Jussien and V. Barichard. The PaLM system: explanation-based constraint programming. In Proceedings of TRICS: Techniques foR Implementing Constraint programming Systems, a post-conference workshop of CP
2000, pages 118-133, Singapore, Sept. 2000.
[25] R. K. Keller, R. Schauer, S. Robitaille, and P. Page, Pattern-based reverseengineering of design components. Proceedings of the 21st International Conference on Software Engineering (ICSE), pp 226-235. 1999.
[26] Foutse Khomh, Yann-Gael Gueheneuc, Do Design Patterns Impact Software
Quality Positively? Proceedings of the 12th European Conference on Software Maintenance and Reengineering (CSMR), du 1-4 avril 2008, Athenes,
Grece. IEEE Computer Society Press.
[27] C. Kramer and L. Prechelt, “ Design recovery by automated search for
structural design patterns in object-oriented software. ” In Proceedings of
6th International Workshop on Program Compression (IWPC ’98), 1998.
[28] Lexi Homepage. http://lexi.sourceforge.net/
54
[29] J. Niere, W. Schafer, J.P. Wadsack, L. Wendehals, and J. Welsh, “ Towards
Pattern-Based Design Recovery, ” Proc. 24th Int’l Conf. Software Eng.
(ICSE 2002), pp. 338-348, 2002.
[30] J. Paakki, A. Karhinen, J. Gustafsson, L. Nenonen, and A. Verkamo. Software Metrics by Architectural Pattern Mining. In Proceedings of the International Conference on Software: Theory and Practice (16th IFIP World
Computer Congress)., pages 325-332, 2000.
[31] N. Pettersson, W. Lowe and J. Nivre. On Evaluation of Accuracy in Pattern Detection. First InternationalWorkshop on Design Pattern Detection
for Reverse Engineering, October 2006.
[32] PINOT
Homepage.http://www.cs.ucdavis.edu/?shini/research/
pinot/
[33] PTIDEJ Download page. http://www.yann-gael.gueheneuc.net/Work/
Research/PTIDEJ/Download/
[34] Rational Rose website.http://www-01.ibm.com/software/rational/
[35] N. Shi and R. A. Olsson, “ Reverse engineering of design patterns from java
source code. ” 21st IEEE/ACM International Conference on Automated
Software Engineering, 2006.
[36] J. M. Smith and D. Stotts, “ SPQR: Flexible automated design pattern extraction from source code. ” In Proceedings of the 18th IEEE International
Conference on Automated Software Engineering (ASE), 2003.
[37] Sun Microsystems, Inc., 2002. Javae2 SDK, Standard Edition Documentation, version 1.4.1. http://java.sun.com/j2se/1.4.1/docs/index.html
[38] W. Wang and V. Tzerpos, “ Design pattern detection in Eiffel systems. ”
In Proceedings of 12th Working Conference on Reverse Engineering (WCRE ’
05), 2005.
55
[39] Wind River Systems, Inc. Sniff+. http://www.windriver.com/products/
sniff plus/
[40] Nikolaos Tsantalis and Spyros T. Halkidis. Design pattern detection using
similarity scoring. IEEE Trans. Softw. Eng., 32(11):896-909, 2006.
[41] The Trac Homepage. http://trac.edgewall.org/
[42] B. Venners. How to use design patterns - A conversation with Erich Gamma,
part I, May 2005. http://www.artima.com/lejava/articles/gammadp.
html
[43] The Web of Patterns Project Homepage. http://www-ist.massey.ac.nz/
wop/
[44] 深谷和宏, 久保淳人, 鷲崎弘宜, 深澤良彰, パターン適用前の状況を活用した
デザインパターン検出, ソフトウェア工学の基礎ワークショップ (FOSE2007),
pp95-104, November 8-10, 2007.
[45] 小幡拓弥, 塙雅織, 伊藤毅志, 思考ゲームによる合議アルゴリズム単純多数決
の有効性について , 情報処理学会ゲーム情報学研究会報告, Vol.2009-GI-22,
No.2(2009).
56
付録
A. デザインパターン検出ツールの検出範囲
ここには，4.2 節で触れた個々のデザインパターン検出ツールの検出範囲を示
す．DPdT の検出範囲を表 13 に，DPRE を表 14 に，PINOT を表 15 に，WOP
を表 16 にそれぞれ示す．
B. デザインパターン検出ツールの検出件数
ここには，5.1.3 の実験結果で触れたデザインパターン検出ツールの検出件数
を示す．表は各プロジェクトにおける個々の検出ツールの検出件数をデザインパ
ターンの種類ごとに数えたものである．表中の棒線は，その検出ツールがそのデ
ザインパターンを検出可能でないことを表している．JHotDraw 6.0 beta 1 にお
ける検出件数を表 17 に，JHotDraw 5.1 を表 18 に，JRefactory を表 19 に， Lexi
を表 20 にそれぞれ示す．
C. デザインパターン検出ツール間の検出箇所の一致件
数
ここには，5.1.3 の実験結果で触れたデザインパターン検出ツール間の検出箇所
の一致件数を示す．表は各プロジェクトにおける検出ツール間の検出箇所の一致
件数をデザインパターンの種類ごとに数えたものである．表の○種類の数字は，
検出箇所が一致した件数を表している．表中の棒線は，使用している検出ツール
の中でそのデザインパターンを検出可能なものの個数がその件数に満たないこと
を示している．JHotDraw 6.0 beta 1 における検出箇所の一致件数を表 21 に，
JHotDraw 5.1 を表 22 に，JRefactory を表 23 に， Lexi を表 24 にそれぞれ示す．
57
表 13 DPdT のデザインパターンごとの検出範囲
デザインパターン名
ロール名
Factory Method
Factory Method
Prototype
Prototype, Client
Singleton
Singleton
Adapter
Adapter, Adaptee
Command
Command, Receiver
Composite
Composite, Component
Decorator
Decorator, Component
Proxy
Proxy, Real Subject
Observer
Observer, Subject
State
State, Context
Strategy
Strategy, Context
Template Method
Template Method
Visitor
Visitor, Concrete Element
表 14 DPRE のデザインパターンごとの検出範囲
デザインパターン名
ロール名
Adapter
Adapter, Adaptee, Target
Bridge
Abstraction, Implementor, Concrete Implementor
Composite
Composite, Component, Leaf
Facade
Facade, Hidden Classes
Proxy
Proxy, Subject, Real Subject
58
表 15 PINOT のデザインパターンごとの検出範囲
デザインパターン名
ロール名
Factory Method
Factory Method, Concrete Factory Method
Singleton
Singleton
Adapter
Adapter, Adaptee, Adapting Classes
Bridge
abstract, interface
Composite
Composite, Component
Decorator
Decorator, Decoratee
Facade
Facade, Hidden Types
Flyweight
Flyweight Factory
Proxy
Proxy, Proxy Interface
Chain of Responsibility Chain of Resposibility
Mediator
Mediator, Colleagues
Observer
Observer, Subject
State
State, Context, Concrete State
Visitor
Abstract Visitor, Visitee
59
D. デザインパターン検出ツールおよび和集合による併
用結果の検出精度
ここには，5.1.4 の実験結果で触れたデザインパターン検出ツールおよび和集合
による併用結果の検出精度を示す．表は各プロジェクトにおける個々の検出ツー
ルおよび和集合による併用結果について，デザインパターンごとに検出箇所の
TP(True Positive)，FN(False Negative)， FP(False Positive) および適合率，再
現率，F 値を示したものである．JHotDraw 6.0 beta 1 における個々の検出ツー
ルおよび和集合による併用結果の検出精度を表 25 に， JHotDraw 5.1 を表 26 お
よび表 27 に，JRefactory を表 28 に， Lexi を表 29 にそれぞれ示す．
E. 併用アルゴリズムの検出精度
ここには，5.2.3 で触れた併用アルゴリズムの検出精度を示す．表は各プロジェ
クトにおけるそれぞれの併用アルゴリズムによる併用結果について，デザイン
パターンごとに検出箇所の TP(True Positive)，FN(False Negative)， FP(False
Positive) および適合率，再現率，F 値を示したものである．JHotDraw 6.0 beta
1 における個々の検出ツールおよび和集合による併用結果の検出精度を表 30 に，
JHotDraw 5.1 を表 31 および表 32 に，JRefactory を表 33 に， Lexi を表 34 に
それぞれ示す．
60
表 16 WOP のデザインパターンごとの検出範囲
デザインパターン名
ロール名
Abstract Factory
Abstract Factory, Abstract Product, Concrete Factory,
Concrete Product
Singleton
Singleton
Adapter
Adapter, Adaptee, Target
Bridge
Abstraction, Implementor, Refined Abstraction,
Concrete Implementor
Composite
Composite, Component
Proxy
Proxy, Subject, Real Subject
Template Method
Abstract Class, Concrete Class
61
表 17 JHotDraw 6.0 beta 1 における各検出ツールの検出件数
DPdT
DPRE
PINOT
WOP
Abstract Factory
-
-
0
34
Factory Method
9
-
17
-
Prototype
6
-
-
-
Singleton
8
-
0
1
Adapter
33
48
2
59
Bridge
-
147
23
21
Composite
2
1
1
13
Decorator
13
0
5
-
Facade
-
18
21
-
Flyweight
-
-
4
-
Proxy
0
0
4
0
Chain of Responsibility
-
-
5
-
33
-
-
-
Mediator
-
-
103
-
Observer
11
-
0
-
State
94
-
1
-
Strategy
94
-
13
-
Template Method
7
-
0
12
Visitor
1
-
1
0
Command
62
表 18 JHotDraw 5.1 における各検出ツールの検出件数
DPdT
DPRE
PINOT
WOP
Abstract Factory
-
-
0
9
Factory Method
2
-
0
-
Prototype
2
-
-
-
Singleton
2
-
0
1
Adapter
23
40
0
32
Bridge
-
1
1
34
Composite
1
0
0
5
Decorator
3
0
0
-
Facade
-
9
0
-
Flyweight
-
-
1
-
Proxy
0
0
2
1
Chain of Responsibility
-
-
0
-
23
-
-
-
Mediator
-
-
0
-
Observer
4
-
1
-
State
44
-
0
-
Strategy
44
-
1
-
Template Method
5
-
0
0
Visitor
0
-
1
0
Command
63
表 19 JRefactory における各検出ツールの検出件数
DPdT
DPRE
PINOT
WOP
Abstract Factory
-
-
0
2
Factory Method
1
-
8
-
Prototype
0
-
-
-
Singleton
12
-
3
7
Adapter
26
34
12
0
Bridge
-
31
3
0
Composite
0
0
8
0
Decorator
0
0
0
-
Facade
-
9
86
-
Flyweight
-
-
1
-
14
3
29
0
-
-
0
-
26
-
-
-
Mediator
-
-
262
-
Observer
2
-
5
-
State
37
-
2
-
Strategy
37
-
15
-
Template Method
16
-
0
6
2
-
0
0
Proxy
Chain of Responsibility
Command
Visitor
64
表 20 Lexi における各検出ツールの検出件数
DPdT
DPRE
PINOT
WOP
Abstract Factory
-
-
0
1
Factory Method
0
-
3
-
Prototype
0
-
-
-
Singleton
2
-
1
2
Adapter
14
3
0
0
Bridge
-
23
0
0
Composite
0
0
0
0
Decorator
0
0
0
-
Facade
-
3
1
-
Flyweight
-
-
2
-
Proxy
0
0
6
0
Chain of Responsibility
-
-
0
-
14
-
-
-
Mediator
-
-
50
-
Observer
0
-
0
-
State
9
-
0
-
Strategy
9
-
8
-
Template Method
0
-
0
1
Visitor
0
-
0
0
Command
65
表 21 JHotDraw 6.0 beta 1 における検出箇所の一致件数
1 種類 2 種類 3 種類 4 種類
Abstract Factory
34
0
-
-
Factory Method
22
2
-
-
Prototype
6
-
-
-
Singleton
7
1
0
-
Adapter
125
4
3
0
Bridge
154
17
1
-
Composite
13
2
0
0
Decorator
14
2
0
-
Facade
35
2
-
-
Flyweight
4
-
-
-
Proxy
4
0
0
0
Chain of Responsibility
5
-
-
-
Command
33
-
-
-
Mediator
103
-
-
-
Observer
11
0
-
-
State
93
1
-
-
Strategy
97
5
-
-
Template Method
7
6
0
-
Visitor
2
0
0
-
66
表 22 JHotDraw 5.1 における検出箇所の一致件数
1 種類 2 種類 3 種類 4 種類
Abstract Factory
9
0
-
-
Factory Method
2
0
-
-
Prototype
2
-
-
-
Singleton
1
1
0
-
Adapter
57
10
6
0
Bridge
86
12
0
-
Composite
4
1
0
0
Decorator
3
0
0
-
Facade
9
0
-
-
Flyweight
1
-
-
-
Proxy
3
0
0
0
Chain of Responsibility
0
-
-
-
Command
23
-
-
-
Mediator
0
-
-
-
Observer
5
0
-
-
State
44
0
-
-
Strategy
43
1
-
-
Template Method
5
0
0
-
Visitor
1
0
0
-
67
表 23 JRefactory における検出箇所の一致件数
1 種類 2 種類 3 種類 4 種類
Abstract Factory
2
0
-
-
Factory Method
7
1
-
-
Prototype
0
-
-
-
Singleton
3
8
1
-
Adapter
58
7
0
0
Bridge
34
0
0
-
Composite
8
0
0
0
Decorator
0
0
0
-
95
0
-
-
1
-
-
-
24
8
2
0
0
-
-
-
Command
26
-
-
-
Mediator
262
-
-
-
Observer
7
0
-
-
State
35
2
-
-
Strategy
30
11
-
-
Template Method
10
6
0
-
2
0
0
-
Facade
Flyweight
Proxy
Chain of Responsibility
Visitor
68
表 24 Lexi における検出箇所の一致件数
1 種類 2 種類 3 種類 4 種類
Abstract Factory
1
0
-
-
Factory Method
3
0
-
-
Prototype
0
-
-
-
Singleton
0
1
1
-
Adapter
15
1
0
0
Bridge
23
0
0
-
Composite
0
0
0
0
Decorator
0
0
0
-
Facade
4
0
-
-
Flyweight
2
-
-
-
Proxy
6
0
0
0
Chain of Responsibility
0
-
-
-
Command
14
-
-
-
Mediator
50
-
-
-
Observer
0
0
-
-
State
9
0
-
-
Strategy
1
8
-
-
Template Method
1
0
0
-
Visitor
0
0
0
-
表 25 JHotDraw 6.0 beta 1 の Strategy パターンに関する検出ツールごとの検出
精度
TP FP FN
適合率
再現率
F値
DPdT
54
40
11
0.574
0.831
0.679
PINOT
9
4
56
0.692
0.138
0.231
58
44
7
0.569
0.892
0.695
併用 (和集合)
69
表 26 JHotDraw 5.1 における検出ツールごとの検出精度 (1)
パターン名
Adapter
Command
Composite
Decorator
DPRE
PINOT
WOP
和集合
TP/FN/FP 3/165/20 4/164/36
0/168/0
2/166/30
5/163/68
DPdT
適合率
0.130
0.1
0
0.0625
0.0685
再現率
0.0179
0.0238
0
0.0119
0.0298
F値
0.0314
0.0385
0
0.02
0.0415
0/16/23
-/16/-
-/16/-
-/16/-
0/16/23
適合率
0
-
-
-
0
再現率
0
-
-
-
0
F値
0
-
-
-
0
1/4/0
0/5/0
0/5/0
1/4/4
1/4/4
適合率
1
0
0
0.2
0.2
再現率
0.2
0
0
0.2
0.2
F値
0.333
0
0
0.2
0.2
TP/FN/FP
1/0/2
-/1/-
0/1/0
-/1/-
1/0/2
適合率
0.333
-
0
-
0.333
再現率
1
-
0
-
1
0.5
-
0
-
0.5
0/2/2
-/2/-
0/2/0
-/2/-
0/2/2
TP/FN/FP
TP/FN/FP
F値
Factory
TP/FN/FP
Method
適合率
0
-
0
-
0
再現率
0
-
0
-
0
F値
0
-
0
-
0
1/1/3
-/2/-
0/2/1
-/2/-
1/1/4
適合率
0.25
-
0
-
0.2
再現率
0.5
-
0
-
0.5
0.333
-
0
-
0.286
Observer
TP/FN/FP
F値
70
表 27 JHotDraw 5.1 における検出ツールごとの検出精度 (2)
パターン名
Prototype
Singleton
State
DPdT DPRE
TP/FN/FP
WOP
和集合
2/0/0
-/2/-
-/2/-
-/2/-
2/0/0
適合率
1
-
-
-
1
再現率
1
-
-
-
1
F値
1
-
-
-
1
2/0/0
-/2/-
0/2/0
1/1/0
2/0/0
適合率
1
-
0
1
1
再現率
1
-
0
0.5
1
F値
1
-
0
0.667
1
TP/FN/FP 1/1/43
-/2/-
0/2/0
-/2/-
1/1/43
TP/FN/FP
適合率
0.0227
-
0
-
0.0227
再現率
0.5
-
0
-
0.5
0.435
-
0
-
0.435
TP/FN/FP 3/1/41
-/4/-
0/4/1
-/4/-
3/1/41
F値
Strategy
PINOT
適合率
0.0682
-
0
-
0.0682
再現率
0.75
-
0
-
0.75
0.125
-
0
-
0.125
F値
71
表 28 JRefactory における検出ツールごとの検出精度
パターン名
Adapter
DPdT
DPRE
PINOT
WOP
和集合
TP/FN/FP 0/16/26
0/16/34
0/16/12
0/16/0
0/16/65
適合率
0
0
0
0
0
再現率
0
0
0
0
0
F値
0
0
0
0
0
0/1/1
-/1/-
0/1/8
-/1/-
0/1/8
Factory
TP/FN/FP
Method
適合率
0
-
0
-
0
再現率
0
-
0
-
0
F値
0
-
0
-
0
TP/FN/FP
1/1/11
-/2/-
0/2/3
1/1/6
1/1/11
適合率
0.0833
-
0
143
0.833
再現率
0.5
-
0
0.5
0.5
0.143
-
0
0.222
0.143
0/1/37
-/1/-
0/1/2
-/1/-
0/1/37
適合率
0
-
0
-
0
再現率
0
-
0
-
0
F値
0
-
0
-
0
2/0/0
-/2/-
0/2/0
-/2/-
2/0/0
適合率
1
-
0
-
1
再現率
1
-
0
-
1
F値
1
-
0
-
1
Singleton
F値
State
Visitor
TP/FN/FP
TP/FN/FP
72
表 29 Lexi における検出ツールごとの検出精度
パターン名
Builder
Observer
Singleton
WOP 和集合
DPdT
DPRE
PINOT
-/1/-
-/1/-
-/1/-
-/1/-
-/1/-
適合率
-
-
-
-
-
再現率
-
-
-
-
-
F値
-
-
-
-
-
0/8/0
-/8/-
0/8/0
-/8/-
0/8/0
適合率
0
-
0
-
0
再現率
0
-
0
-
0
F値
0
-
0
-
0
2/0/0
0/2/0
1/1/0
2/0/0
2/0/0
適合率
1
0
1
1
1
再現率
1
0
0.5
1
1
F値
1
0
0.667
1
1
TP/FN/FP
TP/FN/FP
TP/FN/FP
表 30 JHotDraw 6.0 beta 1 の Strategy パターンに関する併用アルゴリズムの検
出精度
TP
FP
FN
適合率
再現率
F値
和集合
58
44
7
0.569
0.892
0.695
多数決
11
8
54
0.579
0.169
0.262
適性値付き和集合
58
44
7
0.569
0.892
0.695
73
表 31 JHotDraw 5.1 における併用アルゴリズムの検出精度 (1)
パターン名
Adapter
Command
Composite
Decorator
和集合
多数決
適性値付き和集合
TP/FN/FP 5/163/68
4/164/62
4/164/68
適合率
0.0685
0.0606
0.0556
再現率
0.0298
0.0238
0.0238
F値
0.0415
0.0342
0.0333
0/16/23
0/16/0
0/16/2
適合率
0
0
0
再現率
0
0
0
F値
0
0
0
1/4/4
1/4/2
1/4/4
適合率
0.2
0.333
0.2
再現率
0.2
0.2
0.2
F値
0.2
0.25
0.2
TP/FN/FP
1/0/2
0/1/0
0/1/1
適合率
0.333
0
0
再現率
1
0
0
0.5
0
0
0/2/2
0/2/0
0/2/2
TP/FN/FP
TP/FN/FP
F値
Factory
TP/FN/FP
Method
適合率
0
0
0
再現率
0
0
0
F値
0
0
0
1/1/4
1/1/0
1/1/4
適合率
0.2
1
0.2
再現率
0.5
0.5
0.5
0.286
0.667
0.286
Observer
TP/FN/FP
F値
74
表 32 JHotDraw 5.1 における併用アルゴリズムの検出精度 (2)
パターン名
Prototype
Singleton
State
和集合
多数決
適性値付き和集合
2/0/0
0/2/0
1/1/0
適合率
1
0
1
再現率
1
0
0.5
F値
1
0
0.667
2/0/0
1/1/0
2/0/0
適合率
1
1
1
再現率
1
0.5
1
F値
1
0.667
1
TP/FN/FP 1/1/43
0/2/1
1/1/43
TP/FN/FP
TP/FN/FP
適合率
0.0227
0
0.0227
再現率
0.5
0
0.5
0.435
0
0.435
TP/FN/FP 3/1/41
1/3/1
3/1/41
F値
Strategy
適合率
0.0682
0.5
0.682
再現率
0.75
0.25
0.75
0.125
0.333
0.125
F値
75
表 33 JRefactory における併用アルゴリズムの検出精度
パターン名
Adapter
和集合
多数決
適性値付き和集合
TP/FN/FP 0/16/65 0/16/59
0/16/65
適合率
0
0
0
再現率
0
0
0
F値
0
0
0
0/1/8
0/1/0
0/1/7
Factory
TP/FN/FP
Method
適合率
0
0
0
再現率
0
0
0
F値
0
0
0
TP/FN/FP
1/1/11
1/1/7
1/1/9
適合率
0.0833
0.125
0.1
再現率
0.5
0.5
0.5
0.143
0.2
0.167
0/1/37
0/1/4
0/1/37
適合率
0
0
0
再現率
0
0
0
F値
0
0
0
2/0/0
0/2/0
2/0/0
適合率
1
0
1
再現率
1
0
1
F値
1
0
1
Singleton
F値
State
Visitor
TP/FN/FP
TP/FN/FP
76
表 34 Lexi における併用アルゴリズムの検出精度
パターン名
Builder
Observer
Singleton
和集合
多数決
適性値付き和集合
-/1/-
-/1/-
-/1/-
適合率
-
-
-
再現率
-
-
-
F値
-
-
-
0/8/0
0/8/0
0/8/0
適合率
0
0
0
再現率
0
0
0
F値
0
0
0
2/0/0
2/0/0
0/2/0
適合率
1
1
0
再現率
1
1
0
F値
1
1
0
TP/FN/FP
TP/FN/FP
TP/FN/FP
77

Download Report