ソフトウェア設計における意思決定ガイド ラインとしてのデザインパターンのモデル http://twitter.com/asatohan 研究のスコープ • ソフトウェアパターンの一種としてのデザイン パターンをまずは対象とする • GoFのパターン以外については今後の課題 • パターン言語については今後の課題 事実・前提 設計行為とデザインパターン • 一般的な設計の観点 – 異なる設計者に、それぞれ同じ問題を与えても、異なる設計解を出 力する[1] – ある設計解は、設計者の経験と知識によって決まる[1] – 設計者に同じ問題を与えても、いつ与えるかによって異なる設計解を 出力する[1] – 設計者の設計経験と知識は更新される – ある設計が解決した設計問題を初めから完全に理解することは困難 • デザインパターンの観点 – パターンの記述内容はパターン記述者の設計経験と知識に依存する 目次 • 研究背景 • 課題 • 提案 研究背景 • 設計行為には、意思決定の側面がある[3] • デザインパターンは、設計における意思決定を 支援するためのガイドライン • 適切な意思決定をガイドするためには、各デザ インパターンの妥当性の検証や評価は重要 • 各デザインパターンの妥当性の検証・評価は十 分に行われていない 研究背景 意思決定ガイドラインとして パターンを利用 ガイドラインとなる 意思決定 プロセス デザインパターン 出力する 意思決定経験 構造化される 意思決定経験の構造化 課題 1. 意思決定のガイドラインとしてのデザインパ ターンの構造の明確化 2. パターン構造の妥当性の検証と評価のプロ セスの明確化 • ガイドラインとしてのパターンの妥当性 – パターン利用者が適切な意思決定を行えるよう に構造化されている度合い 提案 1. 意思決定のモデルに基づくデザインパター ンのメタモデル 2. パターンモデルに基づき、パターンの妥当 性の検証を行うプロセスのモデル 提案モデルの概観 メタモデル層 意思決定メタモデル 拡張する デザインパターンメタモデル パターン指向設計メタモデル モデル層 従う 従う : 意思決定モデル 表す 拡張する 従う : パターン指向設計モデル : デザインパターンモデル 表す 表す 現実世界 : モデル 表す 意思決定ガイドラインと してパターンを利用 意思決定 メタモデル 従う デザインパターン モデル化の 対象ドメイン 課題解決の手順 モデル化の対象とする概念要素の特定と整理 出力 意思決定の 概念要素 デザインパターンの 概念要素 意思決定ガイドラインとして パターン利用の概念要素 入力 概念要素のメタモデル化 出力 意思決定 メタモデル デザインパターン メタモデル パターン指向設計 メタモデル 入力 メタモデルに基づくデザインパターンの妥当性検証 課題解決の手順： モデル化対象とする概念要素の特定と整理 デザインパターンの従来定義 基づく 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パターン解 Decoratorパターン 代替案間の関係 満たせない カスタマイズ可能な1つのクラス : 代替案 拡張容易性：評価基準 満たす 学習容易性：評価基準 デバッグ容易性：評価基準 満たせない Decoratorパターン解 : 代替案 満たす オブジェクトの同一性：評価基準 ：設計原則 Decoratorパターン 例題 • 機能要求 – 主要な機能の実現 • パラメータとして受け取った文字列を表示する – 主機能に関連する１つ以上の副機能の実現 • 主機能の実行前に “*** ”を、実行後に “ ***”を表示 する • 主機能の実行前に “[[[ ”を、実行後に “ ]]]”を表示する Decoratorパターン カスタマイズ可能な1つのクラス ConcreteOutput + print(s : String) : void + decorateStar + decorateBracket + undecorateStar + undecorateBracket Decoratorパターン Decoratorパターン解 <<interface>> Output + print(s : String) : void ConcreteOutput OutputDecorator + print(s : String) : void + print(s : String) : void StarDecorator BracketDecorator + print(s : String) : void + 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 FunctionBehaviour-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の例
© Copyright 2024 ExpyDoc
