• Save
"Problem Frame Patterns" 紹介
Upcoming SlideShare
Loading in...5
×
 

"Problem Frame Patterns" 紹介

on

  • 2,315 views

 

Statistics

Views

Total Views
2,315
Views on SlideShare
2,314
Embed Views
1

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

"Problem Frame Patterns" 紹介 "Problem Frame Patterns" 紹介 Presentation Transcript

  • Problem Frame Patterns Rebecca Wirfs-Brock, Paul Taylor, James Noble 2007 年 1 月 11 日 紹介者 : 佐藤匡剛 PLoP’06
  • 概要
    • M. Jackson の 5 つの基本問題フレームを、パターンの形に書き直した
    • パターンにすることで現場への普及を狙う
    • 問題フレームとパターンの類似・相違点、関連性を考察する
    • 著者らが新しい問題フレームを発表する訳ではない
  • 目次
    • 問題と解決法
      • 問題フレームの紹介、問題フレームの例、
      • 問題フレームを好きになる理由、問題フレームの使い方、
      • 「現象学」について、本論の動機、本論のアプローチ
    • 問題フレームパターン
      • Required Behavior 問題フレーム、 Commanded Behavior 問題フレーム、
      • Information Display 問題フレーム、 Simple Workpieces 問題フレーム、
      • Transformation 問題フレーム
    • 評価と結論
  • 1. 問題と解決法
    • ソフトウェア開発者はコードによって問題を解決する
      • 顧客を悩ます問題を素早く解決することが仕事
      • 「解決法空間」=アーキテクチャ、設計、パターン、イディオム
    • パターンは優れた問題解決の道具である
      • ベストプラクティスのテンプレート
      • 問題と文脈( context )が適切に与えられれば、正しい解決法を導き出せる
    • 「問題空間」に注目することにどんな意義があるのか?
  • パターンの問題点
    • 問題と文脈が十分に理解されている、ということを前提にしている
      • まだ十分に理解できていなかったら?
      • 漠然とした問題空間にいるとしたら?
    • 問題空間を扱うパターンは存在するのか
      • システムの分析/概念化の前段階を支援するパターン
      • 存在するとしたら、設計パターンとの関係は?
      • 問題構造を考えることが、どのようにソフトウェアのアーキテクチャ/設計に結びつくのか?
  • 1.1. 問題フレームの紹介
    • 問題フレーム( PF )とは
      • M. Jackson が提唱する問題空間の分類メカニズム
      • ドメイン・システム間の構造/関係に注目して、汎用的な問題型を捉える
      • 「現象学」の哲学に基づく
        • 概念、ドメイン、現象、機械(開発すべきソフトウェア)の相互作用する世界に確固とした視点を与える
  • 問題の記述方法
    • 問題は、機械と適用領域(ドメイン)で構成
    • 機械とドメインとは共有現象で結ばれている
    • 問題の文脈は、状況( scene )を示すだけで機能( function )は示さない
    • 要求( requirement )・・・機械の機能を指示( dictate )するもの(記述( describe )はしない)
      • 機械に対してでなく、文脈に対して表現される
      • 機械に対して表現すると、問題への理解が未熟なまま解決法に飛びつくリスクを背負ってしまうため
  • 1.2. 問題フレームの例
    • 問題フレーム・・・汎用的で抽象的な問題の構造
    (論文より)
  • Required Behavior フレーム
    • 自動制御を含んだ問題クラスの構造を一般化したもの
      • ex) 温度調整を行なうサーモスタット
    • 機械 ・・・ Controller
    • ドメイン ・・・ Controlled Domain
    • 要求 ・・・ Desired Behavior
    (論文より)
  • Simple Workpieces フレーム
    • 文章や画像を編集するソフトウェアツールを扱う問題クラスの構造を一般化したもの
    (論文より)
  • 問題フレームの特徴
    • PF は、あらゆるシステムやアーキテクチャが解こうとする問題の基本構造を抽象化したもの
    • PF を採用すると問題の構成要素が明らかになるので、仕様作成やドメイン分析に役立つ
    • 仕様/分析/設計/実装のどこかで対応される、事実・述語・表明・不変項・観察・分類・関連・振舞の根拠が PF の中に見出される
  • 1.3. 問題フレームを好きになる理由
    • アーキテクトや開発者にとって:
      • 顧客の問題を正しく解決するソフトウェアを作るのが仕事
      • 問題を適切に記述することで、提案したソフトウェアが正しい問題に取り組んでいることを確信できる
    • アナリスト( PFer )にとって:
      • ドメインの性質と機械に求められる動作を調査/記述するのが仕事
      • PF1 つひとつが「ミクロな方法論」
      • 問題構造のテンプレートを選ぶことで、正しい質問ができ、正しいものを仕様化できる
      • 仕事のやり方が、細部を分析することから、フレームを選んでその構成要素と現実の問題との対応づけを考えることに移る
        • ⇒  ノウハウの再利用はパターンの方向性と一致する
  • 1.4. 問題フレームの使い方
    • PF カタログから候補を選び、その PF と実際の問題との対応付けを行なう
      • 現実世界の問題はたいてい複数の PF と対応付く
      • 複雑な問題は、より小さな問題へ分割する
    • PF を問題に当てはめる過程で、仕様化と分析の方法がガイドされる
      • どこを質問すべきか、どこが論点となるのか
      • それぞれの PF が独自の「ミクロな方法論」
      • 「形式的に」なる必要はない
    • PF の適用は、 2 つの作業を同時並行ですること
      • 問題に適合する PF を探す作業
      • PF のミクロな方法論を実行して問題への適合度を検証する作業
  • フレーム関心事( frame concern )
    • 各 PF は「フレーム関心事」をもつ
      • ドメインの特徴と、それらが満たすべき相互作用の記述
        • 要求、ドメイン記述、仕様の 3 つ
      • 様式化された議論を可能にする
    • 問題に正しい PF を選択したかの確認に使える
      • 間違った PF の場合、フレーム関心事が示唆する記述は意味をなさない
      • そのフレーム関心事に基づいて、正しいと確信できるような仕様を書くことは困難
  • Required Behavior のフレーム関心事 (論文より) 仕様 ドメイン記述 要求
  • 問題空間における「関心事の分離」
    • PF は、正しい質問を誘導することで仕様書の質を向上させる
    • さらに、問題空間の関心事を分離するという利点もある
      • 必要最小限の記述を促し、かつ機械に現象世界の快適な居場所があることを保証する
      • よく統合された必要最小限のソフトウェアを提供 ⇒ 顧客価値の最大化
  • 1.5. 「現象学」について
    • 従来の手法(機能的分割など)
      • アナリストが発見/理解すべき客観的現実が存在することを前提
      • アナリストの仕事は、ドメインの不変的性質を記述してシステム設計者へ渡すこと
    • PF は逆に、現象学的態度をとる
      • 現象学 = 唯一表明可能なのは、観察された振舞だけであるとする立場
        • 現象学者は、観察された振舞から理論と記述を組み立てていく
      • PFer は、ドメインで観察される現象から出発する
        • 高次元のアーキテクチャやプロセスでなく、小さく的を絞ったドメインの定義と記述につとめる
  • 現象の種類
    • 個別現象( individual phenomena )
      • イベント( event ) ・・・ ある時刻/場所で生起した分割不可能な出来事
      • 実体( entity ) ・・・ 永続し、属性や状態を変化させるもの
      • 値( value ) ・・・ 時間/空間の外にある不変のもの
    • 関係( relationships between individual phenomena )
      • 状態( state ) ・・・ 時間によって真偽が変わる多項関係
      • 真実( truth ) ・・・ 不変の多項関係
      • 役割( role ) ・・・ イベントとそれに参加する個別現象との関係
  • 1.6. 本論の動機
    • PF は、研究者の間では広く受け入れられつつある
      • 2 つの書籍( Jackson1995, 2001 )
      • 2 つの国際ワークショップ( IWAAPF2005, 2006 )
    • 開発現場での受容はイマイチ
    • 動機
      • パターンコミュニティにとってなぜ PF なのか?
      • パターン形式にすることで何が期待できるか?
  • PF とパターンの類似と相違
    • 類似点
      • 構造的分類、問題の分割/抽象化を要求
      • 見本構造の選択・適合・調整が必要
      • 選択後は、具体的なプロセス(ミクロな方法論)を指示
      • 複数の組み合わせが可能
    • 相違点
      • PF の成果物は記述、パターンはアーキテクチャ(コードの構造)
      • PF はトップダウン、パターンはボトムアップ
      • PF は問題空間のテンプレート、パターンは解決法空間のフォース->解決法マップ
      • PF は方法論中心、パターンは成果物/資産中心
  • パターンコミュニティにとってなぜ PF なのか?
    • PF はパターンに非常によく似ている
      • 両者の関係を理解する必要がある
      • 本論は、類似点/相違点を明らかにする試み
    • パターンコミュニティはパターンの普及に貢献しつつある
      • 経験を、 PF の普及にも活かせるかもしれない
    • パターンに興味をもつ人は、 PF にも興味を抱くはずだ
  • パターン形式にすることで何が期待できるか?
    • PF とパターンの比較で湧き上がる疑問点
      • PF とは仕様に関するパターンなのか?
      • PF は問題空間のパターンなのか?
      • PF をパターンとして扱うことに価値はあるか? あるとすれば、そのフォースや解決法とは?
      • PF と設計パターンを結びつけることに意義はあるか?
      • PF の中に「パターン言語」「生成性」「発生」といったアレクサンダー的概念は見出せるか?
    • 本論は、このすべてに回答できる訳ではない
  • 著者らの動機
    • PF とパターンの関係を探求することで、両者に共通する基盤を見つけたい
    • よく知っているパターンの概念と関連付けることで、 PF について学びたい
    • PF の「非形式的」で「アジャイル」なアプローチの可能性を探り、実践的な技術として確立したい
  • 1.7. 本論のアプローチ
    • 以下を除いてオリジナルの部分はない
      • PF とパターンを関連させたアイデア
      • パターンの実装に関する議論
      • パターンに用いた例題
      • Jackson と違い、現実世界よりもコンピュータ側の現象とドメインにわずかに力点を移したこと
      • 評価と結論の部分
    • 【参考】 パターンコミュニティの基本理念(一部)
    •  オリジナリティの積極的な無視。 パターン著者は、そこに記述されている解決法の原発案者である必要はない。
    •                      (『 Pattern-Oriented Software Architecture 』より)
  • 2. 問題フレームパターン
    • Jackson の 5 つの基本 PF をパターンとして取り上げる
      • Required Behavior PF パターン
        • ある条件を満たすように振舞が制御される、世界の一部がある。問題は、こうした制御を行なう機械を構築することである。
      • Commanded Behavior PF パターン
        • オペレータが発行する命令に従って振舞が制御される、世界の一部がある。問題は、オペレータのコマンドを受理して制御を行なう機械を構築することである。
      • Simple Workpieces PF パターン
        • ユーザがある種のコンピュータ処理可能なテキスト、画像オブジェクト、その他同様の構造物を作成したり編集したりできるようなツールが必要である。編集対象は、編集後にコピーや印刷、解析、その他の方法で利用することができる。問題は、このようなツールとして動作する機械を構築することである。
      • Information Display PF パターン
        • その状態や振舞についてのある種の情報が必要となるような、世界の一部がある。問題は、その情報を取得して、要求された場所に要求された形で表示する機械を構築することである。
      • Transformation PF パターン
        • ある要求された出力に変換されなければならない、所与のデータがある。出力データは特定の形式をしており、あるルールに従って入力データから導出されたものでなければならない。問題は、入力から要求された出力を生成するような機械を構築することである。
  • パターンの書式
    • 問題( Problem )
      • PF が扱う問題についての短い定義
    • 例( Example )
      • 全パターンを通して、電子メールクライアントの仕様を記述する例を用いる
    • 構造( Structure )
      • 問題の一般化された構造の図と構成要素
    • フレーム関心事( Frame Concern )
      • 正しい解決法を実現するときに機械が満たさなければならない全体的な条件
      • 設計パターンの「協調動作( collaboration )」の項に近い
    • 議論( Discussion )
      • 問題を分析/設計/実装する上での検討事項
    • 変種( Variants )
      • PF の派生形と、関連する PF について
  • ドメイン図 (論文より) 医療モニタリング機械の例
  • ドメイン図の構成要素
    • ドメイン( domain )
      • 現実世界の現象の集合
    • 機械( machine )
      • 我々が構築すべきドメイン(解決法)
    • 共有現象( shared phenomena )
      • 複数ドメインで共有される現象
    • 記述( description )
    • 要求( requirement )
      • ドメインの状態や操作に関する制約条件
    • 仕様( specification )
    • 表明( assertion )
  • ドメイン図の構成要素(つづき)
    • 因果的ドメイン( causal domain )
      • 因果律に基づき予測可能なドメイン
    • 命令可能ドメイン( biddable domain )
      • 物理的だが動作が予測不能なドメイン(主に人間)
    • 字句ドメイン( lexical domain )
      • データの物理的な記号表現
    C B X
  • 問題フレームパターン カタログ
  • 2.1. Required Behavior 問題フレーム
    • 問題
      • ある条件を満たすように振舞が制御される、世界の一部がある。問題は、こうした制御を行なう機械を構築することである。
    • 電子メールクライアントは、メールサーバにメールを送信したり、メールサーバからメールを受信したりする。
      • メールクライアント ・・・ 機械
      • メールサーバ ・・・ 因果的ドメイン
      • Send 、 Check 、 Get ・・・ 共有現象
      • 【要求】 所定の間隔で、メールサーバに対してメールの送信/受信が行なわれること
    (論文より)
  • 構造
    • 構成要素
      • 制御機械( Control Machine ) ・・・ 構築対象。制御対象ドメインを制御するもの
      • 制御対象ドメイン( Controlled Domain ) ・・・ 機械に制御されるべき世界の一部
      • 要求された振舞( Required Behavior ) ・・・ ドメインが機械にどのように制御されなければならないかの記述
    (論文より)
  • フレーム関心事
    • 「制御機械」の振舞 と、
    • 「制御対象ドメイン」の属性 が、
    • 「要求された振舞」 を保証する
    (論文より)
    • 例題のフレーム関心事を解決する
      • フレーム関心事を例題に当てはめると:
        • 【仕様】 メールクライアントの振舞 と、
          • メールサーバとのインタフェースでどのように振る舞うか
        • 【ドメイン記述】 メールサーバの属性 が、
          • メールがどのようにサーバ上で受信/蓄積/転送されるか
        • 【要求】 クライアント・サーバ間でメールが送受信されること を保証する
          • メールがどのように送受信されるべきか
      • 要求・ドメイン記述・機械の仕様が、すべて矛盾なく書かれていることを確認する
  • 議論
    • この問題の分析は 2 つの作業に分かれる
      • 制御対象ドメインの動作を分析する作業
      • 制御対象ドメインを適切に制御するために、制御機械が持たねばならない振舞の仕様化作業
    • 問題を PF に当てはめていく過程で、 PF は以下のような質問をガイドするだろう
      • 制御対象ドメインのどの外的状態が制御されるべきか?
      • どんな外的状態を取りうるか? 状態はどのように遷移するか?
      • 機械はどの状態遷移を命令すべきか?
      • 機械が主導すべきアクションを、いつ、どのように機械は判断するか?
    • 機械-制御対象ドメイン間が信頼できない接続だった場合
      • 制御対象ドメインの予想される状態が、機械が意図した結果と食い違う可能性がある
      • 食い違いを機械がどうやって発見し、対処するかの記述が必要になる
    • そもそも、機械が結果を確認する必要があるのかどうか
      • 結果を毎回確認すべき場合と、後で食い違いが発見されたら対処すればいい場合とがある
      • 「メールを送信先が受信したかをユーザが確認したい」ような例
        • その場合、メールに「受取確認」要求タグを埋め込むなどして実現する
  • 変種
    • 接続ドメイン( Connection Domain )
      • 接続ドメインを問題に含めるかどうか
        • 機械と制御対象ドメインが直接接続していると見なせるかどうかによる
        • 接続に複雑さがある場合、接続ドメインを導入する
      • 接続ドメインを導入する場合:
        • 接続ドメインの属性を記述する
        • 隣接ドメイン/機械とどう相互作用するかを記述する
    (論文より)
    • 設定ドメイン( Configuration Domain )
      • 制御機械の設定をドメイン化するのが有効なこともある
        • 設定ドメインをユーザが操作する場合、そこは Commanded Behavior フレームになる
        • ある PF のドメインが、別の PF に登場してもよい
        • その場合、複数 PF の要求が矛盾しないよう注意すること
      • 制御機能実現のために、機械が接続している他のドメインを追加するのもよい
        • メールクライアントは、メールを格納するためにメールボックスドメインと接続している
      • 設定ドメインの例
    (論文より)
  • 2.2. Commanded Behavior 問題フレーム
    • 問題
      • オペレータが発行する命令に従って振舞が制御される、世界の一部がある。問題は、オペレータのコマンドを受理して制御を行なう機械を構築することである。
  • (省略)
  • 2.3. Information Display 問題フレーム
    • 問題
      • その状態や振舞についてのある種の情報が必要となるような、世界の一部がある。問題は、その情報を取得して、要求された場所に要求された形で表示する機械を構築することである。
  • (省略)
  • 2.4. Simple Workpieces 問題フレーム
    • 問題
      • ユーザがある種のコンピュータ処理可能なテキスト、画像オブジェクト、その他同様の構造物を作成したり編集したりできるようなツールが必要である。編集対象は、編集後にコピーや印刷、解析、その他の方法で利用することができる。問題は、このようなツールとして動作する機械を構築することである。
  • (省略)
  • 2.5. Transformation 問題フレーム
    • 問題
      • ある要求された出力に変換されなければならない、所与のデータがある。出力データは特定の形式をしており、あるルールに従って入力データから導出されたものでなければならない。問題は、入力から要求された出力を生成するような機械を構築することである。
  • (省略)
  • 3. 評価と結論
    • PF パターンは他のパターンとどう関連しているか?
      • パターンは物事の設計に関わるものである
      • 仕様を書くことは、それ自体が設計行為である
        • 仕様はシステムの内部構造でなく、全体の設計
      • PF は問題空間のものだが、同時に解決法(パターン)も示唆する
        • Translation PF ⇒ パーサ構築技術を示唆
        • Commanded Behavior PF ⇒ Command パターンを示唆
        • Required Behavior PF ⇒ イベント処理、有限状態機械、応答型システムの設計パターンを示唆
      • ただし、 PF とパターンとのリンクはあくまで希薄
        • 設計パターンは、解決法に内在する緊張を解くためのもの
        • 潜在的な解決法の探索ガイドとして PF を見ることは有効
  • PF パターンをどう使えばよいか
    • PF を実際の問題に当てはめてみる
      • 「ここは Simple Workpieces じゃないか?」「 Transformation だろうか、 Required Behavior だろうか?」「どの PF が問題の中心だろうか?」
      • 有意義な疑問を導くことができる
      • 補助的な問題や、分割すべき問題が発見できる
    • 要求を書いてみる
      • 記述が形式的になりすぎる心配はない
      • 要求と、表明・願望・技術的制約とを明確に区別できる
      • より厳密な状態モデル・イベント記述・振舞ルールの必要性を認識することができる
  • 課題
    • 他の分析手法に精通したアナリストは、 PF に興味をもつが、すぐには適用できないと感じるようだ
    • PF は他の分析手法と置き換わるものではない
      • 他の手法との統合に向けて試行錯誤が必要
    • PF のパターン化によって、ユーザ獲得を期待する
      • ユーザの経験をぜひレポートしてほしい