ソフトウェア設計における意思決定ガイドラインとしてのデザインパターンのモデル http://twitter.com/asatohan

研究のスコープ ソフトウェアパターンの一種としてのデザインパターンをまずは対象とする GoFのパターン以外については今後の課題 パターン言語については今後の課題

事実・前提 設計行為とデザインパターン 一般的な設計の観点 デザインパターンの観点 異なる設計者に、それぞれ同じ問題を与えても、異なる設計解を出力する[1] ある設計解は、設計者の経験と知識によって決まる[1] 設計者に同じ問題を与えても、いつ与えるかによって異なる設計解を出力する[1] 設計者の設計経験と知識は更新される ある設計が解決した設計問題を初めから完全に理解することは困難 デザインパターンの観点 パターンの記述内容はパターン記述者の設計経験と知識に依存する

目次 研究背景 課題 提案

研究背景 設計行為には、意思決定の側面がある[3] デザインパターンは、設計における意思決定を支援するためのガイドライン 適切な意思決定をガイドするためには、各デザインパターンの妥当性の検証や評価は重要 各デザインパターンの妥当性の検証・評価は十分に行われていない

意思決定ガイドラインとして パターンを利用 研究背景 意思決定ガイドラインとして パターンを利用 ガイドラインとなる 意思決定 プロセス デザインパターン 出力する 意思決定経験 構造化される 意思決定経験の構造化

課題 意思決定のガイドラインとしてのデザインパターンの構造の明確化 パターン構造の妥当性の検証と評価のプロセスの明確化 ガイドラインとしてのパターンの妥当性 パターン利用者が適切な意思決定を行えるように構造化されている度合い

提案 意思決定のモデルに基づくデザインパターンのメタモデル パターンモデルに基づき、パターンの妥当性の検証を行うプロセスのモデル

意思決定ガイドラインとしてパターンを利用 提案モデルの概観 メタモデル層 拡張する 意思決定メタモデル デザインパターンメタモデル パターン指向設計メタモデル 拡張する モデル層 従う 従う : 意思決定モデル : デザインパターンモデル 従う : パターン指向設計モデル 表す 表す メタモデル 表す 従う 現実世界 意思決定ガイドラインとしてパターンを利用 : モデル 表す モデル化の 対象ドメイン 意思決定 デザインパターン

課題解決の手順 モデル化の対象とする概念要素の特定と整理 意思決定の 概念要素 デザインパターンの 概念要素 出力 意思決定の 概念要素 デザインパターンの 概念要素 意思決定ガイドラインとしてパターン利用の概念要素 入力 概念要素のメタモデル化 出力 意思決定 メタモデル デザインパターン メタモデル パターン指向設計 メタモデル 入力 メタモデルに基づくデザインパターンの妥当性検証

課題解決の手順： モデル化対象とする概念要素の特定と整理 基づく デザインパターンの従来定義 GoFのデザインパターン記述 デザインパターンの概念要素の特定 デザインパターンの概念要素 意思決定の概念要素の特定 モデル化対象とする概念要素を規定 意思決定の概念要素 パターン指向設計の概念要素の特定 パターン指向設計の概念要素 概念要素のメタモデル化

課題解決の手順： 概念要素のメタモデル化

課題解決の手順： メタモデルに基づくデザインパターンの 妥当性検証

デザインパターンの概念要素の特定 繰り返し発生する問題 繰り返し発生する解 フォース

パターン指向設計 パターン指向設計 設計解の種類 設計解の妥当性 デザインパターンの記述内容をガイドラインとし、プログラム構造に関する意思決定を行うプロセス 設計解の種類 (1) 記述されているパターン解 (2) 記述されている代替案 (3) 記述されていない代替案 設計解の妥当性 パターンの記述内容の妥当性に依存

ソフトウェア設計における意思決定のモデル：要素 問題 満たさなければならない要求 問題空間 Pspace 問題の集合 現在の問題 開発者が現在抱えている問題 解 要求を満たすソフトウェア構造 解空間 Sspace 解の集合 代替案 現在の問題を満たすとして選択された解候補 代替案の集合 選択した解 代替案の集合から選択した解 代替案の評価基準 代替案間の利点・欠点を決める基準となる要素 例：拡張容易性 評価結果 ある評価基準に基づく評価結果 設計経験と知識 ある開発者が持つ設計経験と設計に関係する知識 代替案、代替案の評価基準、評価結果、選択した解を決める要素

ソフトウェア設計における意思決定のモデル: プロセス 代替案の出力 評価基準による代替案の比較 意思決定

ソフトウェア設計における意思決定のモデル 解空間 問題空間 代替案の集合 満たす 現在の問題 満たす 満たせない 選択した解 満たす 問題 評価基準 解 問題 解 代替案 決める 現在の問題 選択した解 設計経験と知識 代替案 評価基準 設計経験と知識 評価結果 解は問題を満たす 解は問題を満たせない

ソフトウェア設計における意思決定のモデル： プロセス構造 現在の問題 代替案の出力 代替案 設計経験と知識 代替案の集合 評価基準 代替案の比較 評価結果 設計経験と知識 評価結果の集合 意思決定 選択した解 設計経験と知識 入力 変換 出力 プロセス構造[1]

ソフトウェア設計における意思決定のメタモデル 1 出力 1 選択した解 解決する 1 選択される 1 1 解決する 2..* 1 1..* 現在の問題 代替案 意思決定 1 入力 1..* 入力 評価結果 出力 1..* 代替案の比較 代替案の出力 1 評価基準 入力 入力 1 1 設計経験と知識 モデル : 代替案 : 現在の問題 : 評価結果 : 代替案 : 評価基準 : 代替案の出力 : 設計経験と知識

意思決定のモデルに基づく デザインパターンのモデル：要素 経験した問題 開発者が経験した問題 抽象化された経験した問題 抽象化の向き：問題を比較し、似た部分が繰り返されることを認識 抽象化：繰り返され似た部分を抽象化 一般化された問題 抽象化された問題を一般化して表現 経験した解 開発者が経験した解 抽象化された経験した解 繰り返し起こる似た解 一般化された代替案 繰り返し起こる似た代替案 評価基準 デザインパターン記述 一般化された問題、解、代替案、評価基準を対応付ける記述

意思決定のモデルに基づく デザインパターンのモデル：プロセス 経験した問題の抽象化 抽象化された問題の一般化

意思決定のモデルに基づく デザインパターンのモデル 一般化された問題 デザインパターン記述 非形式的に記述 非形式的に記述 一般化 抽象化された問題の集合 一般化 抽象化 抽象化された経験した問題 経験した問題 抽象化 経験した問題 経験した問題 抽象化 経験した問題 抽象化された経験した問題 一般化された問題 経験した問題の抽象化 抽象化された問題の一般化

意思決定のモデルに基づく デザインパターンのモデル：プロセス構造 経験した問題 経験した問題の抽象化 抽象化された問題 抽象化された問題の集合 抽象化された問題の一般化 一般化された問題

意思決定のモデルに基づく デザインパターンのメタモデル

パターン指向設計のモデル： 要素 現在の問題 抽象化された現在の問題

パターン指向設計のモデル： プロセス 現在の問題の抽象化 問題一致の確認

パターン指向設計のモデル 一般化された問題 パターン記述 問題の一致確認 抽象化 抽象化された現在の問題 現在の問題 現在の問題の抽象化

パターン指向設計のモデル： プロセス構造 現在の問題 現在の問題の抽象化 抽象化された現在の問題 一般化された問題 抽象化された現在の問題 問題一致の確認 一般化された問題

パターン指向設計のメタモデル

妥当性検証可能な パターンメタモデルの要件 問題モデル要素の詳細化 異なる解としての代替案の変換の基準を方向付けるモデル要素

パターンメタモデルのモデル要素 機能要求（Function） 振る舞い要求（Behavior） 非機能要求（Quality） 代替案（Structure） 機能要求・振る舞い要求を満たす解構造 評価基準（Criterion） 評価結果 設計原則（Design Principle） ある代替案から他の代替案への変換の向きを決める

デザインパターンメタモデル メタモデル 1..* 2..* 代替案 評価結果 満たす 1..* 1 要求 評価基準 設計原則 機能要求 振る舞い要求 非機能要求 モデル 拡張容易性：評価基準 カスタマイズ可能な1つのクラス : 代替案 Decoratorパターン解 : 代替案 デバッグ容易性：評価基準 オブジェクトの同一性：評価基準

デザインパターンモデルの定義プロセス 検証可能な デザインパターン メタモデル デザインパターン メタモデル GoFのSingleton パターン記述 従う 従う 解釈・抽象化 Singleton : デザインパターン記述 Singleton : デザインパターンモデル Decorator : デザインパターン記述 解釈・抽象化 Decorator : デザインパターンモデル GoFの Decorator パターン記述

メタモデルの評価方法 評価基準 AO DPのサンプルコードを利用

例題：Decoratorパターン

Decoratorパターン 機能要求 主要な機能の実現 主機能に関連する１つ以上の副機能の実現 例：文字を表示するウィンドウ 例：ウィンドウ機能が必要とする境界線やスクロール機能

Decoratorパターン 振る舞い要求 主機能は、実行時に0以上存在する 副機能は、実行時に必要であるときとないときがある 例：ウィンドウは実行時に複数存在する 副機能は、実行時に必要であるときとないときがある 例：文字がウィンドウのサイズに収まらない場合にスクロール機能が必要 ある副機能は、他の副機能の振る舞いに影響を及ぼさない 例： 副機能の振る舞いには、順序性がある 例：境界線を表示した後に、スクロールバーを表示する 副機能の振る舞いの順序は、実行時に決まる

Decoratorパターン 非機能要求 新しい副機能（責任）の追加

Decoratorパターン 代替案 カスタマイズ可能な1つのクラス クラス継承 Strategyパターン Decoratorパターン解

Decoratorパターン 評価基準 Decoratorパターン解 クラス継承 カスタマイズ可能な1つのクラス Strategyパターン解 オブジェクトの同一性（満たせない） 学習容易性（満たせない） デバッグ容易性（満たせない） クラス継承 柔軟性（満たせない） 責任数の制限（満たせない） カスタマイズ可能な1つのクラス 拡張容易性（満たせない） 拡張の独立性 Strategyパターン解

Decoratorパターン 代替案間の関係 満たせない カスタマイズ可能な1つのクラス : 代替案 拡張容易性：評価基準 満たす 学習容易性：評価基準 デバッグ容易性：評価基準 満たす 満たせない Decoratorパターン解 : 代替案 オブジェクトの同一性：評価基準 ：設計原則

Decoratorパターン 例題 機能要求 主要な機能の実現 主機能に関連する１つ以上の副機能の実現 パラメータとして受け取った文字列を表示する 主機能に関連する１つ以上の副機能の実現 主機能の実行前に “*** ”を、実行後に “ ***”を表示する 主機能の実行前に “[[[ ”を、実行後に “ ]]]”を表示する

Decoratorパターン カスタマイズ可能な1つのクラス ConcreteOutput + print(s : String) : void + decorateStar + decorateBracket + undecorateStar + undecorateBracket

Decoratorパターン Decoratorパターン解 <<interface>> Output + print(s : String) : void ConcreteOutput + print(s : String) : void OutputDecorator + print(s : String) : void StarDecorator + print(s : String) : void BracketDecorator + print(s : String) : void

Decoratorパターン AO Decoratorパターン解 AspectJによるDecoratorパターンの実装 <<Aspect>> StarDecorator ConcreteOutput + print(s : String) : void <<Aspect>> BaracketDecorator

Decoratorパターン 代替案 内容 カスタマイズ可能な 1つのクラス OO Decorator AO Decorator 機能 要求 主要な機能の実現 満たす 主機能に関連する１つ以上の副機能の実現 振る舞い 要求 主機能は、実行時に0から1つ以上存在する 副機能は、実行時に必要であるときとないときがある 満たせない ある副機能は、他の副機能の振る舞いに影響を及ぼさない 副機能の振る舞いには、順序性がある

Decoratorパターン AO Decoratorパターン解 副機能は、実行時に必要であるときとないときがある AspectJにおけるアスペクトは、クラスの全てのオブジェクトに対してアドバイスが実行される。したがって、この実装では副機能は常に実行されるため満たせない 副機能の振る舞いには、順序性がある declare precedenceは、振る舞いの順序を静的に決めるため満たせない

提案モデルの有効性の検証 Decoratorパターンのパターンモデル

今後の課題

調査の必要な項目 パターンマイニング Design Rationaleとの関係

参考文献 [1] J. S Gero and U. Kannengiesser, A Function-Behaviour-Structure ontology of processes, AIEDAM, 2008. [2] J. S Gero, Situated Design Computing: Principles, in BHV Topping, (ed), Civil Engineering Computations: Tools and Techniques, Saxe-Coburg Publications, Stirlingshire, UK, pp. 25-35. [3] Gero, J. S. (1990). Design prototypes: a knowledge representation schema for design, AI Magazine, 11(4): 26-36.

メモ・疑問・気になる点 パターンのコンセプト自体の妥当性を証明するのか、それとも個々のパターンの妥当性を証明するのか AlexanderがNotes本で否定したことをやろうとしていないのかどうか 原則の組み合わせ 意思決定は問題の構造を理解したうえで行わなければならない

メモ・疑問・気になる点 どんな代替案の集合が出力されるかは、設計知識と経験によって異なる 代替案は、代替案でない場合がある

メモ・疑問・気になる点 実際のパターン解を採用するかどうかは、問題の文脈や設計者の主観に依存する 例：Strategyパターンの場合、条件分岐がどのくらい複雑になれば、 Strategyパターンの解構造を採用するのか。 新たな代替案の提案は、新たな評価基準を引き起こす 例：Whiteoakの例