More Related Content
"Formalizing Architectural Connection" 紹介 "Documenting Frameworks using Patterns" 紹介 Similar to "Problem Frame Patterns" 紹介 (13)
DDD 20121106 SEA Forum November Pattern mining-scrum gatheringtokyo20130115 1997 情報処理学会論文誌-自然言語要求仕様からオブジェクト指向設計図を自動生成するシステム [JAWS2012]CRFを用いた メディア情報の抽出とLinked Data化 ～ ソーシャルメディアとマスメディアの比較事例 ～ 2011 icse-reverse engineering feature models More from Tadayoshi Sato (6)
Red Hat Tech Night 2019.5 - Camel 3 and Beyond... Red Hat Tech Night 2018 - Apache Camel Camel on Cloud by Christina Lin ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation "Detecting Defects in Object Oriented Designs: Using Reading Techniques to In... "The Coming-of-Age of Software Architecture Research" 紹介 "Problem Frame Patterns" 紹介
- 2. 概要 M. Jackson の 5 つの基本問題フレームを、パターンの形に書き直した パターンにすることで現場への普及を狙う 問題フレームとパターンの類似・相違点、関連性を考察する 著者らが新しい問題フレームを発表する訳ではない
- 3. 目次 問題と解決法 問題フレームの紹介、問題フレームの例、 問題フレームを好きになる理由、問題フレームの使い方、 「現象学」について、本論の動機、本論のアプローチ 問題フレームパターン Required Behavior 問題フレーム、 Commanded Behavior 問題フレーム、 Information Display 問題フレーム、 Simple Workpieces 問題フレーム、 Transformation 問題フレーム 評価と結論
- 4. 1. 問題と解決法 ソフトウェア開発者はコードによって問題を解決する 顧客を悩ます問題を素早く解決することが仕事 「解決法空間」＝アーキテクチャ、設計、パターン、イディオム パターンは優れた問題解決の道具である ベストプラクティスのテンプレート 問題と文脈（ context ）が適切に与えられれば、正しい解決法を導き出せる 「問題空間」に注目することにどんな意義があるのか？
- 6. 1.1. 問題フレームの紹介 問題フレーム（ PF ）とは M. Jackson が提唱する問題空間の分類メカニズム ドメイン・システム間の構造／関係に注目して、汎用的な問題型を捉える 「現象学」の哲学に基づく 概念、ドメイン、現象、機械（開発すべきソフトウェア）の相互作用する世界に確固とした視点を与える
- 9. Required Behavior フレーム 自動制御を含んだ問題クラスの構造を一般化したもの ex) 温度調整を行なうサーモスタット 機械 ・・・ Controller ドメイン ・・・ Controlled Domain 要求 ・・・ Desired Behavior （論文より）
- 12. 1.3. 問題フレームを好きになる理由 アーキテクトや開発者にとって： 顧客の問題を正しく解決するソフトウェアを作るのが仕事 問題を適切に記述することで、提案したソフトウェアが正しい問題に取り組んでいることを確信できる アナリスト（ PFer ）にとって： ドメインの性質と機械に求められる動作を調査／記述するのが仕事 PF1 つひとつが「ミクロな方法論」 問題構造のテンプレートを選ぶことで、正しい質問ができ、正しいものを仕様化できる 仕事のやり方が、細部を分析することから、フレームを選んでその構成要素と現実の問題との対応づけを考えることに移る ⇒ ノウハウの再利用はパターンの方向性と一致する
- 13. 1.4. 問題フレームの使い方 PF カタログから候補を選び、その PF と実際の問題との対応付けを行なう 現実世界の問題はたいてい複数の PF と対応付く 複雑な問題は、より小さな問題へ分割する PF を問題に当てはめる過程で、仕様化と分析の方法がガイドされる どこを質問すべきか、どこが論点となるのか それぞれの PF が独自の「ミクロな方法論」 「形式的に」なる必要はない PF の適用は、 2 つの作業を同時並行ですること 問題に適合する PF を探す作業 PF のミクロな方法論を実行して問題への適合度を検証する作業
- 14. フレーム関心事（ frame concern ） 各 PF は「フレーム関心事」をもつ ドメインの特徴と、それらが満たすべき相互作用の記述 要求、ドメイン記述、仕様の 3 つ 様式化された議論を可能にする 問題に正しい PF を選択したかの確認に使える 間違った PF の場合、フレーム関心事が示唆する記述は意味をなさない そのフレーム関心事に基づいて、正しいと確信できるような仕様を書くことは困難
- 17. 1.5. 「現象学」について 従来の手法（機能的分割など） アナリストが発見／理解すべき客観的現実が存在することを前提 アナリストの仕事は、ドメインの不変的性質を記述してシステム設計者へ渡すこと PF は逆に、現象学的態度をとる 現象学 ＝ 唯一表明可能なのは、観察された振舞だけであるとする立場 現象学者は、観察された振舞から理論と記述を組み立てていく PFer は、ドメインで観察される現象から出発する 高次元のアーキテクチャやプロセスでなく、小さく的を絞ったドメインの定義と記述につとめる
- 18. 現象の種類 個別現象（ individual phenomena ） イベント（ event ） ・・・ ある時刻／場所で生起した分割不可能な出来事 実体（ entity ） ・・・ 永続し、属性や状態を変化させるもの 値（ value ） ・・・ 時間／空間の外にある不変のもの 関係（ relationships between individual phenomena ） 状態（ state ） ・・・ 時間によって真偽が変わる多項関係 真実（ truth ） ・・・ 不変の多項関係 役割（ role ） ・・・ イベントとそれに参加する個別現象との関係
- 19. 1.6. 本論の動機 PF は、研究者の間では広く受け入れられつつある 2 つの書籍（ Jackson1995, 2001 ） 2 つの国際ワークショップ（ IWAAPF2005, 2006 ） 開発現場での受容はイマイチ 動機 パターンコミュニティにとってなぜ PF なのか？ パターン形式にすることで何が期待できるか？
- 20. PF とパターンの類似と相違 類似点 構造的分類、問題の分割／抽象化を要求 見本構造の選択・適合・調整が必要 選択後は、具体的なプロセス（ミクロな方法論）を指示 複数の組み合わせが可能 相違点 PF の成果物は記述、パターンはアーキテクチャ（コードの構造） PF はトップダウン、パターンはボトムアップ PF は問題空間のテンプレート、パターンは解決法空間のフォース->解決法マップ PF は方法論中心、パターンは成果物／資産中心
- 21. パターンコミュニティにとってなぜ PF なのか？ PF はパターンに非常によく似ている 両者の関係を理解する必要がある 本論は、類似点／相違点を明らかにする試み パターンコミュニティはパターンの普及に貢献しつつある 経験を、 PF の普及にも活かせるかもしれない パターンに興味をもつ人は、 PF にも興味を抱くはずだ
- 22. パターン形式にすることで何が期待できるか？ PF とパターンの比較で湧き上がる疑問点 PF とは仕様に関するパターンなのか？ PF は問題空間のパターンなのか？ PF をパターンとして扱うことに価値はあるか？ あるとすれば、そのフォースや解決法とは？ PF と設計パターンを結びつけることに意義はあるか？ PF の中に「パターン言語」「生成性」「発生」といったアレクサンダー的概念は見出せるか？ 本論は、このすべてに回答できる訳ではない
- 24. 1.7. 本論のアプローチ 以下を除いてオリジナルの部分はない PF とパターンを関連させたアイデア パターンの実装に関する議論 パターンに用いた例題 Jackson と違い、現実世界よりもコンピュータ側の現象とドメインにわずかに力点を移したこと 評価と結論の部分 【参考】 パターンコミュニティの基本理念（一部） オリジナリティの積極的な無視。 パターン著者は、そこに記述されている解決法の原発案者である必要はない。 （『 Pattern-Oriented Software Architecture 』より）
- 25. 2. 問題フレームパターン Jackson の 5 つの基本 PF をパターンとして取り上げる Required Behavior PF パターン ある条件を満たすように振舞が制御される、世界の一部がある。問題は、こうした制御を行なう機械を構築することである。 Commanded Behavior PF パターン オペレータが発行する命令に従って振舞が制御される、世界の一部がある。問題は、オペレータのコマンドを受理して制御を行なう機械を構築することである。
- 26. Simple Workpieces PF パターン ユーザがある種のコンピュータ処理可能なテキスト、画像オブジェクト、その他同様の構造物を作成したり編集したりできるようなツールが必要である。編集対象は、編集後にコピーや印刷、解析、その他の方法で利用することができる。問題は、このようなツールとして動作する機械を構築することである。 Information Display PF パターン その状態や振舞についてのある種の情報が必要となるような、世界の一部がある。問題は、その情報を取得して、要求された場所に要求された形で表示する機械を構築することである。
- 27. Transformation PF パターン ある要求された出力に変換されなければならない、所与のデータがある。出力データは特定の形式をしており、あるルールに従って入力データから導出されたものでなければならない。問題は、入力から要求された出力を生成するような機械を構築することである。
- 28. パターンの書式 問題（ Problem ） PF が扱う問題についての短い定義 例（ Example ） 全パターンを通して、電子メールクライアントの仕様を記述する例を用いる 構造（ Structure ） 問題の一般化された構造の図と構成要素 フレーム関心事（ Frame Concern ） 正しい解決法を実現するときに機械が満たさなければならない全体的な条件 設計パターンの「協調動作（ collaboration ）」の項に近い 議論（ Discussion ） 問題を分析／設計／実装する上での検討事項 変種（ Variants ） PF の派生形と、関連する PF について
- 30. ドメイン図の構成要素 ドメイン（ domain ） 現実世界の現象の集合 機械（ machine ） 我々が構築すべきドメイン（解決法） 共有現象（ shared phenomena ） 複数ドメインで共有される現象 記述（ description ） 要求（ requirement ） ドメインの状態や操作に関する制約条件 仕様（ specification ） 表明（ assertion ）
- 31. ドメイン図の構成要素（つづき） 因果的ドメイン（ causal domain ） 因果律に基づき予測可能なドメイン 命令可能ドメイン（ biddable domain ） 物理的だが動作が予測不能なドメイン（主に人間） 字句ドメイン（ lexical domain ） データの物理的な記号表現 C B X
- 35. 構造 構成要素 制御機械（ Control Machine ） ・・・ 構築対象。制御対象ドメインを制御するもの 制御対象ドメイン（ Controlled Domain ） ・・・ 機械に制御されるべき世界の一部 要求された振舞（ Required Behavior ） ・・・ ドメインが機械にどのように制御されなければならないかの記述 （論文より）
- 37. 例題のフレーム関心事を解決する フレーム関心事を例題に当てはめると： 【仕様】 メールクライアントの振舞 と、 メールサーバとのインタフェースでどのように振る舞うか 【ドメイン記述】 メールサーバの属性 が、 メールがどのようにサーバ上で受信／蓄積／転送されるか 【要求】 クライアント・サーバ間でメールが送受信されること を保証する メールがどのように送受信されるべきか 要求・ドメイン記述・機械の仕様が、すべて矛盾なく書かれていることを確認する
- 38. 議論 この問題の分析は 2 つの作業に分かれる 制御対象ドメインの動作を分析する作業 制御対象ドメインを適切に制御するために、制御機械が持たねばならない振舞の仕様化作業 問題を PF に当てはめていく過程で、 PF は以下のような質問をガイドするだろう 制御対象ドメインのどの外的状態が制御されるべきか？ どんな外的状態を取りうるか？ 状態はどのように遷移するか？ 機械はどの状態遷移を命令すべきか？ 機械が主導すべきアクションを、いつ、どのように機械は判断するか？
- 40. 変種 接続ドメイン（ Connection Domain ） 接続ドメインを問題に含めるかどうか 機械と制御対象ドメインが直接接続していると見なせるかどうかによる 接続に複雑さがある場合、接続ドメインを導入する 接続ドメインを導入する場合： 接続ドメインの属性を記述する 隣接ドメイン／機械とどう相互作用するかを記述する （論文より）
- 41. 設定ドメイン（ Configuration Domain ） 制御機械の設定をドメイン化するのが有効なこともある 設定ドメインをユーザが操作する場合、そこは Commanded Behavior フレームになる ある PF のドメインが、別の PF に登場してもよい その場合、複数 PF の要求が矛盾しないよう注意すること 制御機能実現のために、機械が接続している他のドメインを追加するのもよい メールクライアントは、メールを格納するためにメールボックスドメインと接続している
- 45. 2.3. Information Display 問題フレーム 問題 その状態や振舞についてのある種の情報が必要となるような、世界の一部がある。問題は、その情報を取得して、要求された場所に要求された形で表示する機械を構築することである。
- 47. 2.4. Simple Workpieces 問題フレーム 問題 ユーザがある種のコンピュータ処理可能なテキスト、画像オブジェクト、その他同様の構造物を作成したり編集したりできるようなツールが必要である。編集対象は、編集後にコピーや印刷、解析、その他の方法で利用することができる。問題は、このようなツールとして動作する機械を構築することである。
- 49. 2.5. Transformation 問題フレーム 問題 ある要求された出力に変換されなければならない、所与のデータがある。出力データは特定の形式をしており、あるルールに従って入力データから導出されたものでなければならない。問題は、入力から要求された出力を生成するような機械を構築することである。
- 51. 3. 評価と結論 PF パターンは他のパターンとどう関連しているか？ パターンは物事の設計に関わるものである 仕様を書くことは、それ自体が設計行為である 仕様はシステムの内部構造でなく、全体の設計 PF は問題空間のものだが、同時に解決法（パターン）も示唆する Translation PF ⇒ パーサ構築技術を示唆 Commanded Behavior PF ⇒ Command パターンを示唆 Required Behavior PF ⇒ イベント処理、有限状態機械、応答型システムの設計パターンを示唆 ただし、 PF とパターンとのリンクはあくまで希薄 設計パターンは、解決法に内在する緊張を解くためのもの 潜在的な解決法の探索ガイドとして PF を見ることは有効
- 52. PF パターンをどう使えばよいか PF を実際の問題に当てはめてみる 「ここは Simple Workpieces じゃないか？」「 Transformation だろうか、 Required Behavior だろうか？」「どの PF が問題の中心だろうか？」 有意義な疑問を導くことができる 補助的な問題や、分割すべき問題が発見できる 要求を書いてみる 記述が形式的になりすぎる心配はない 要求と、表明・願望・技術的制約とを明確に区別できる より厳密な状態モデル・イベント記述・振舞ルールの必要性を認識することができる
- 53. 課題 他の分析手法に精通したアナリストは、 PF に興味をもつが、すぐには適用できないと感じるようだ PF は他の分析手法と置き換わるものではない 他の手法との統合に向けて試行錯誤が必要 PF のパターン化によって、ユーザ獲得を期待する ユーザの経験をぜひレポートしてほしい
