2つのコントローラ
オブジェクト指向のソフトウェア開発をしていると、2つのコントローラに出会う。1つはMVC（Model View Controller）のコントローラ、もう1つはヤコブソンのロバストネス分析に出てくるバウンダリ、コントローラ、エンティティのコントローラだ。
この2つは、名前も一緒だし、役割もなんとなく似通っているので混同してしまいがちだが、本来はまったく別物の概念である。混同してしまうと、アプリケーションの設計が大きく揺らいでしまうことになる。
MVCのコントローラは、GUI画面からのユーザの入力をビジネスロジックに渡す役割のものであり、一方ロバストネス分析のコントローラは、業務のモデル（ドメインモデル）を適切に制御してある業務処理を実現するためのもので、ビジネスロジックそのものである。MVCのCは、ユーザインタフェースのCであり、ロバストネス分析のCはビジネスロジックのCなのだ。
きちんと分けて考えるべき概念なのに、名前が同じなので混乱してしまう。なにか良い別々の呼び名はないものかと思っていたら、マーチン・ファウラーがそれぞれの呼び名を考えていた。
・入力コントローラ（input controller） ＝ MVCのコントローラ
・ユースケースコントローラ（usecase controller） ＝ ロバストネス分析のコントローラ
この呼び分けがいいんじゃないかと思う。
この2つは、名前も一緒だし、役割もなんとなく似通っているので混同してしまいがちだが、本来はまったく別物の概念である。混同してしまうと、アプリケーションの設計が大きく揺らいでしまうことになる。
MVCのコントローラは、GUI画面からのユーザの入力をビジネスロジックに渡す役割のものであり、一方ロバストネス分析のコントローラは、業務のモデル（ドメインモデル）を適切に制御してある業務処理を実現するためのもので、ビジネスロジックそのものである。MVCのCは、ユーザインタフェースのCであり、ロバストネス分析のCはビジネスロジックのCなのだ。
きちんと分けて考えるべき概念なのに、名前が同じなので混乱してしまう。なにか良い別々の呼び名はないものかと思っていたら、マーチン・ファウラーがそれぞれの呼び名を考えていた。
- マーチン・ファウラー, 長瀬 嘉秀, 株式会社 テクノロジックアート
- エンタープライズ アプリケーションアーキテクチャパターン
・入力コントローラ（input controller） ＝ MVCのコントローラ
・ユースケースコントローラ（usecase controller） ＝ ロバストネス分析のコントローラ
この呼び分けがいいんじゃないかと思う。
パターンと Hypertext との親和性
パターンと Hypertext とは、親和性が非常に高い。Web上では、ブラウズ可能なパターンカタログがいくつか公開されているので、列挙しておこう。
また、ほとんどすべてのパターンは他のパターンとの関連が明記されている（GoFであれば、「関連するパターン」がそうだ）。あるパターンが部分的に含んでいる問題を解決するパターンや、そのパターンの代替として使えるパターンなど、パターンは網の目状に互いに関連し合っている。
こうしたパターンの構造は、私たちが日々親しんでいる Hypertext の構造とまったく同じだ（Hypertext との親和性が高いことについては、GoFのひとりであるR. Johnson自身も論文の中で指摘している）。
この親和性については、実際に使ってみると痛いほどよく分かる。GoFの『デザインパターン』の日本語版には、付録としてGoFパターンを Hypertext 化したものがCD-ROMで付いてくる。洋書ですでにもっている方も、この書籍に限っては、日本語版も手元に置いておくことをお勧めしたい。私の場合、この付録HTMLを自分のノートPCにコピーしておいて、いつでもブラウズできるようにしてある。
一度 HTML版パターンの良さを知ってしまうと、他のパターンも全部HTMLで欲しいと思うのだが、他のパターン本には残念ながらそういう特典は付いていない。私としては、FowlerのアナリシスパターンとEAAパターン、AlurらのJ2EEパターン、EvansのDDDパターンなどは、いつも手元に置いていたいと思う。
パターン本には、すべからく日本語版のGoF本のようにHTML版が付属してくるような時代になることを、望んでやまない。
・EAAパターンのカタログパターンはひとつひとつが独立していて、程度の差はあれ、なんらかの形で構造化されている。もっとも有名なGoFパターンであれば、「目的」「別名」「動機」「適用可能性」「構造」「構成要素」「協調関係」「結果」「実装」「サンプルコード」「使用例」「関連するパターン」といった具合だ。
・EAIパターンのカタログ
・リファクタリングのカタログ
また、ほとんどすべてのパターンは他のパターンとの関連が明記されている（GoFであれば、「関連するパターン」がそうだ）。あるパターンが部分的に含んでいる問題を解決するパターンや、そのパターンの代替として使えるパターンなど、パターンは網の目状に互いに関連し合っている。
こうしたパターンの構造は、私たちが日々親しんでいる Hypertext の構造とまったく同じだ（Hypertext との親和性が高いことについては、GoFのひとりであるR. Johnson自身も論文の中で指摘している）。
この親和性については、実際に使ってみると痛いほどよく分かる。GoFの『デザインパターン』の日本語版には、付録としてGoFパターンを Hypertext 化したものがCD-ROMで付いてくる。洋書ですでにもっている方も、この書籍に限っては、日本語版も手元に置いておくことをお勧めしたい。私の場合、この付録HTMLを自分のノートPCにコピーしておいて、いつでもブラウズできるようにしてある。
- Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides
- オブジェクト指向における再利用のためのデザインパターン
一度 HTML版パターンの良さを知ってしまうと、他のパターンも全部HTMLで欲しいと思うのだが、他のパターン本には残念ながらそういう特典は付いていない。私としては、FowlerのアナリシスパターンとEAAパターン、AlurらのJ2EEパターン、EvansのDDDパターンなどは、いつも手元に置いていたいと思う。
パターン本には、すべからく日本語版のGoF本のようにHTML版が付属してくるような時代になることを、望んでやまない。
XPと椅子
XP（Extreme Programming）にとって大事なものとはなんだろうか？ テストファースト、ペアプログラミング、40時間労働・・・ XPには重要な要素がさまざまあるが、それらと並んで大事なのは「椅子」である。
Kent Beckらが提唱するXPでは、なによりも職場の環境が重視される。粗末な環境に置かれていては、プログラマは決してよい精神状態を保っていられるはずがなく、したがってプログラマの精神的な活動の産物であるプログラムもよいものが生産されるはずがない、という信念がそこにはある。
こうした働く環境を重視するXPの考え方は、おそらくTom DeMarcoらの『ピープルウェア』の影響を強く受けたものだと思われる。XPで語られている多くのことが、10年以上前のこの書籍でも同様に提唱されているからだ。
Kent Beckは、職場環境の中でも、とくに椅子の重要性を説いている。
椅子の重要性は、なにもXPに限った話ではなく、ソフトウェア開発に共通して言えることだ。パソコンそのものを除いて、開発中にプログラマが最も長時間接触しているのが椅子だからである。椅子の良し悪しは、プログラマの精神状態に影響する。そして、それは成果物であるプログラムの良し悪しに直結する。
どんな椅子がもっとも心地よくプログラミングできるかを考えることは、単なる趣味の話ではなく、ソフトウェア開発にとっての普遍的なテーマである。
参考文献：
Kent Beckらが提唱するXPでは、なによりも職場の環境が重視される。粗末な環境に置かれていては、プログラマは決してよい精神状態を保っていられるはずがなく、したがってプログラマの精神的な活動の産物であるプログラムもよいものが生産されるはずがない、という信念がそこにはある。
こうした働く環境を重視するXPの考え方は、おそらくTom DeMarcoらの『ピープルウェア』の影響を強く受けたものだと思われる。XPで語られている多くのことが、10年以上前のこの書籍でも同様に提唱されているからだ。
Kent Beckは、職場環境の中でも、とくに椅子の重要性を説いている。
「TDDで使用すべき物理設定は何か。 → 必要であれば、他の家具すべてケチっても、本当に良質の椅子を用意すべきだ。
背中が痛いと、よいプログラミングはできない。しかし、組織はチームに毎月100,000ドルを費やしても、良質の椅子に10,000ドルを費やすことはない。
筆者は、コンピュータには安価で粗末な折りたたみ式のテーブルを使用し、見つけた椅子の中で最高の椅子を購入する。机のスペースは広く、容易に増やすことができるので、午前も午後も、新鮮にプログラミングを行うことができる。
ペアプログラミングを行っている時は、快適な姿勢を取るべきである。机をきれいにし、キーボードがスムーズに行き来するようにする。パートナーは2人とも、ドライブ中はキーボードの真ん前に、快適に座ることができないといけない。筆者の好きな指導方法は、コードに取り組んでいるペアの後ろに立ち、優しくキーボードを移動させて、記述している人が快適な姿勢を取れるようにする方法である。」 （Kent Beck著『テスト駆動開発入門』より）
椅子の重要性は、なにもXPに限った話ではなく、ソフトウェア開発に共通して言えることだ。パソコンそのものを除いて、開発中にプログラマが最も長時間接触しているのが椅子だからである。椅子の良し悪しは、プログラマの精神状態に影響する。そして、それは成果物であるプログラムの良し悪しに直結する。
どんな椅子がもっとも心地よくプログラミングできるかを考えることは、単なる趣味の話ではなく、ソフトウェア開発にとっての普遍的なテーマである。
参考文献：
- ケント ベック, Kent Beck, 長瀬 嘉秀, テクノロジックアート
- テスト駆動開発入門
- トム・デマルコ, ティモシー・リスター, 松原 友夫, 山浦 恒央
- ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵
- Charlotte Fiell, Peter Fiell
- 1000 Chairs (Taschen 25)
パターンの次世代
ソフトウェアのパターンを巡る運動に、変化の兆しがあるようだ。
Gang-of-Fourが『デザインパターン』を書き上げてから、10年が経つ。この本から始まり、これまでいくつもの書籍が、ソフトウェア開発の一側面に隠されているパターンをカタログ化し、パターン言語の体系を構築しようと試みてきた。たとえば、以下の書籍がそうした流れの中に位置づけられる。
・『Pattern Languages of Program Design』シリーズ
・F. Buschmannらの『Pattern-Oriented Software Architecture』
・M. Stalらの『Pattern-Oriented Software Architecture, Volume 2』
・M. Fowlerの『アナリシスパターン』
・M. Fowlerの『リファクタリング』
・M. Fowlerらの『エンタープライズアプリケーションアーキテクチャパターン』
・K. Beckの『Smalltalkベストプラクティスパターン』
・D. Alurらの『J2EEパターン』
これらの書籍が扱うソフトウェア開発上の段階はさまざまである。デザインパターンは設計段階のパターンを対象とするものであるが、分析の段階を対象とするものもある。またプログラミングの段階のパターン、いわゆるイディオムと呼ばれるものもあるし、ソフトウェア全体を俯瞰するアーキテクチャのパターンもある。
しかし、共通しているのは、対象とする段階において埋もれていたパターンを、なんとかして名づけ、記録しようという意志が貫かれていることである。どの書籍も、対象のパターンを体系化したい、という動機によって書かれている。パターンの書物を書くことが、非常に尊重されている。
こうした「古典的な」パターン書籍に対し、最近、とくに2000年以降、少し別のスタンスで書かれたパターン書籍に出会うようになってきた。私が上記とは違う感覚を覚えているパターン書籍は、たとえば以下のものだ。
・G. Hohpeらの『Enterprise Integration Patterns』
・E. Evansの『Domain-Driven Design』
前者は、複数の業務アプリケーションをメッセージングを通して統合する際に使われるパターンを説明したものであり、後者は、業務領域を分析して得られるドメインモデルと呼ばれるオブジェクト設計を元に、業務アプリケーションの中核となるビジネスロジックをどうやって設計／実装していくか、についてのノウハウをパターン化したものである。
書籍の中身じたいには、「古典的な」パターン書籍とくらべて何か違うものがあるとことさらに指摘できるようなものはない。違いを感じるのは、書籍が書かれる過程でのパターンと書籍との関係である。
『Enterprise Integration Patterns』の著者Hohpeはインタビューの中で、書きたかったのはエンタープライズインテグレーションであってパターンではなかった、と言い切っている。パターン形式が選ばれたのは、たんにパターンがもつ読みやすさ、参照のしやすさの性質が好まれたからなのだ。同様に、Evansも『Domain-Driven Design』の中で、最初はとくに形式をもたずに原稿を書いていたが、レビュアーのアドバイスによってパターン形式で書き直した、と書き残している。
つまり、ここで挙げた2つの書籍はどちらも、パターンを書くために書いたものではなく、著者が言いたいことを上手く伝えるための手段として、書籍の形式としてのパターンが選ばれただけなのだ。
結果的にできあがる書籍は同じようなパターン書籍であったにしても、この両者の執筆スタンスの違いは大きな違いを生み出すと考えられる。
パターンを書籍の一形式として扱う場合、パターンを書く、という行為に対する自制はほとんど効かなくなる。「古典的な」パターンコミュニティにおいては、パターンとは時間の試練によって鍛えられたものであって、決して斬新な発明であってはならないという認識がある。パターンの著者たちは、「実際に三回以上出会ってからでないと、それをパターンとして記述してはならない」というルールをもっている。しかし、パターンを単にコミュニケーションを円滑にするための形式だと捉えてしまうと、こうした厳格な自制は働かなくなっていくだろう。コミュニケーションの手段というエクスキューズによって、よりカジュアルにパターンをでっち上げられるようになる。
（HohpeやEvansが軽い気持ちでパターンを書いたと思っている訳ではない。彼らは長年の経験から、何度も使ってきたノウハウを文書化したはずである。私が指摘したいのは、今後パターンがたんに書籍の一形式になりうる可能性である）
ちなみに、パターンをたんに文書化の一形式として捉えるスタンスじたいは、なにも最近始まったものではない。むしろ、ソフトウェアパターン運動の黎明期からあるものだ（たとえば、OOPSLA'92で発表されたR. Johnsonの論文「Documenting Frameworks Using Patterns」）。最近顕著になってきているのは、このスタンスが、実際に書籍のアプローチとして実践されつつある点である。
パターンを巡る運動は、ここ数年のどこかの時点で、次世代に突入したのではないかと思う。この世代においては、パターンは時の試練に耐えたものではなく、たんに書籍の一形式として選ばれたものである。そこでは、どんな内容の書籍であれパターンの形式で書くことが全的に肯定される。パターン形式の書籍は、読者にとってとても読みやすく、また参照もしやすいからだ。パターン形式は、Hypertextとの親和性が非常に高い点も見逃せない。
私は、こうしたパターンの次世代の流れに対して批判的な気持ちはまったくない。むしろ、非常に歓迎している。フランスの哲学者ジル・ドゥルーズが著書『千のプラトー』で行なった書籍解体の試みが、まったく別の分野で花開いたような感がある。パターンの書物はまるでリゾームのようである。パターン形式は、ポストモダンと呼ばれる現代に見事にマッチしている。
参考文献：
Gang-of-Fourが『デザインパターン』を書き上げてから、10年が経つ。この本から始まり、これまでいくつもの書籍が、ソフトウェア開発の一側面に隠されているパターンをカタログ化し、パターン言語の体系を構築しようと試みてきた。たとえば、以下の書籍がそうした流れの中に位置づけられる。
・『Pattern Languages of Program Design』シリーズ
・F. Buschmannらの『Pattern-Oriented Software Architecture』
・M. Stalらの『Pattern-Oriented Software Architecture, Volume 2』
・M. Fowlerの『アナリシスパターン』
・M. Fowlerの『リファクタリング』
・M. Fowlerらの『エンタープライズアプリケーションアーキテクチャパターン』
・K. Beckの『Smalltalkベストプラクティスパターン』
・D. Alurらの『J2EEパターン』
これらの書籍が扱うソフトウェア開発上の段階はさまざまである。デザインパターンは設計段階のパターンを対象とするものであるが、分析の段階を対象とするものもある。またプログラミングの段階のパターン、いわゆるイディオムと呼ばれるものもあるし、ソフトウェア全体を俯瞰するアーキテクチャのパターンもある。
しかし、共通しているのは、対象とする段階において埋もれていたパターンを、なんとかして名づけ、記録しようという意志が貫かれていることである。どの書籍も、対象のパターンを体系化したい、という動機によって書かれている。パターンの書物を書くことが、非常に尊重されている。
こうした「古典的な」パターン書籍に対し、最近、とくに2000年以降、少し別のスタンスで書かれたパターン書籍に出会うようになってきた。私が上記とは違う感覚を覚えているパターン書籍は、たとえば以下のものだ。
・G. Hohpeらの『Enterprise Integration Patterns』
・E. Evansの『Domain-Driven Design』
前者は、複数の業務アプリケーションをメッセージングを通して統合する際に使われるパターンを説明したものであり、後者は、業務領域を分析して得られるドメインモデルと呼ばれるオブジェクト設計を元に、業務アプリケーションの中核となるビジネスロジックをどうやって設計／実装していくか、についてのノウハウをパターン化したものである。
書籍の中身じたいには、「古典的な」パターン書籍とくらべて何か違うものがあるとことさらに指摘できるようなものはない。違いを感じるのは、書籍が書かれる過程でのパターンと書籍との関係である。
『Enterprise Integration Patterns』の著者Hohpeはインタビューの中で、書きたかったのはエンタープライズインテグレーションであってパターンではなかった、と言い切っている。パターン形式が選ばれたのは、たんにパターンがもつ読みやすさ、参照のしやすさの性質が好まれたからなのだ。同様に、Evansも『Domain-Driven Design』の中で、最初はとくに形式をもたずに原稿を書いていたが、レビュアーのアドバイスによってパターン形式で書き直した、と書き残している。
つまり、ここで挙げた2つの書籍はどちらも、パターンを書くために書いたものではなく、著者が言いたいことを上手く伝えるための手段として、書籍の形式としてのパターンが選ばれただけなのだ。
結果的にできあがる書籍は同じようなパターン書籍であったにしても、この両者の執筆スタンスの違いは大きな違いを生み出すと考えられる。
パターンを書籍の一形式として扱う場合、パターンを書く、という行為に対する自制はほとんど効かなくなる。「古典的な」パターンコミュニティにおいては、パターンとは時間の試練によって鍛えられたものであって、決して斬新な発明であってはならないという認識がある。パターンの著者たちは、「実際に三回以上出会ってからでないと、それをパターンとして記述してはならない」というルールをもっている。しかし、パターンを単にコミュニケーションを円滑にするための形式だと捉えてしまうと、こうした厳格な自制は働かなくなっていくだろう。コミュニケーションの手段というエクスキューズによって、よりカジュアルにパターンをでっち上げられるようになる。
（HohpeやEvansが軽い気持ちでパターンを書いたと思っている訳ではない。彼らは長年の経験から、何度も使ってきたノウハウを文書化したはずである。私が指摘したいのは、今後パターンがたんに書籍の一形式になりうる可能性である）
ちなみに、パターンをたんに文書化の一形式として捉えるスタンスじたいは、なにも最近始まったものではない。むしろ、ソフトウェアパターン運動の黎明期からあるものだ（たとえば、OOPSLA'92で発表されたR. Johnsonの論文「Documenting Frameworks Using Patterns」）。最近顕著になってきているのは、このスタンスが、実際に書籍のアプローチとして実践されつつある点である。
パターンを巡る運動は、ここ数年のどこかの時点で、次世代に突入したのではないかと思う。この世代においては、パターンは時の試練に耐えたものではなく、たんに書籍の一形式として選ばれたものである。そこでは、どんな内容の書籍であれパターンの形式で書くことが全的に肯定される。パターン形式の書籍は、読者にとってとても読みやすく、また参照もしやすいからだ。パターン形式は、Hypertextとの親和性が非常に高い点も見逃せない。
私は、こうしたパターンの次世代の流れに対して批判的な気持ちはまったくない。むしろ、非常に歓迎している。フランスの哲学者ジル・ドゥルーズが著書『千のプラトー』で行なった書籍解体の試みが、まったく別の分野で花開いたような感がある。パターンの書物はまるでリゾームのようである。パターン形式は、ポストモダンと呼ばれる現代に見事にマッチしている。
参考文献：
- F. ブッシュマン, H. ローネルト, M. スタル, R. ムニエ, P. ゾンメルラード, Frank Buschmann, Hans Rohnert, Michael Stal, Regine Meunier, Peter Sommerlad
- ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系
- Michael Stal, Hans Rohnert, Frank Buschmann, Douglas C. Schmidt
- Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects
- マーチン ファウラー, Martin Fowler, 堀内 一, 友野 晶夫, 児玉 公信, 大脇 文雄
- アナリシスパターン―再利用可能なオブジェクトモデル
- マーチン ファウラー, Martin Fowler, 児玉 公信, 平澤 章, 友野 晶夫, 梅沢 真史
- リファクタリング―プログラムの体質改善テクニック
- マーチン・ファウラー, 長瀬 嘉秀, 株式会社 テクノロジックアート
- エンタープライズ アプリケーションアーキテクチャパターン
- ケント ベック, Kent Beck, 梅沢 真史, 皆川 誠, 小黒 直樹, 森島 みどり
- ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集
- Deepak Alur, John Crupi, Dan Malks, 近棟 稔, 吉田 悦万, 小森 美智子, トップスタジオ
- J2EEパターン 第2版
- Gregor Hohpe, Bobby Woolf, Kyle Brown, Conrad F. D Cruz, Martin Fowler, Sean Neville, Michael J. Rettig, Jonathan Simon
- Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
- Martin Fowler, Eric Evans
- Domain-Driven Design: Tackling Complexity in the Heart of Software
- ジル ドゥルーズ, フェリックス ガタリ, Gilles Deleuze, F´elix Guattari, 宇野 邦一, 田中 敏彦, 小沢 秋広
- 千のプラトー―資本主義と分裂症
「問題フレーム」 - 問題のパターン化
デザインパターンとは、ソフトウェアを設計する過程で繰り返し直面する問題に対し、その典型的な解決法（とくにオブジェクト指向によるもの）をセットにしてパターン化したものである。デザインパターンは、先人たちの優れた設計上の解決法を誰もが簡単に利用できること、またコミュニケーションを促進するためのボキャブラリになること、などの理由で非常に有効である。
しかし、デザインパターンは少し解決法に力点を置きすぎている。ある問題に対し、どうやれば効果的に解決できるかと悩んでいるときは非常に強力なツールとなるが、そもそも問題が何なのかを特定しようとしている段階、ソフトウェア開発の段階では「要求定義」と言われる段階においては、ほとんど力になってくれない。
その点では、Martin Fowlerの分析パターンもそう大差はない。分析パターンは、問題（あるいは世界）をどうやってオブジェクト指向に基づいて記述するか、を示したものである。世界は必ずしもオブジェクト指向のような単一の記法だけで表現できるものではない。例えば、太陽が昇るとともに小鳥たちがさえずる状況を記述するとき、太陽が小鳥たちにメッセージを送っている（あるいはメソッドを呼び出している）のでは決してない。また、それを差し引いても、分析パターンは「オブジェクトモデルを作る」という解決法の方に、やはり焦点を置きすぎている。
JSPやJSDなどの設計手法で知られるソフトウェア工学界の権威Michael Jacksonは、「問題フレーム（Probrem Frame）」という方法で、問題そのもののパターン化を試みている。Jacksonは、次の5つの基本的な問題フレームを挙げている。
●要求された振舞（required behaviour）
世界の中では、ある条件に応じてその一部の振舞が制御されなくてはならないことがある。この問題のクラスは、そうした制御を行なう機械（ソフトウェア）を作ること。
●命令された振舞（commanded behaviour）
オペレータの命令によって、世界の振舞が制御されるような状況がある。この問題のクラスは、そのような命令を受け取り、制御を行なう機械を作ること。
●情報表示（information display）
世界のある部分から、その状態などの情報を読み取り、適切な形で表示するような機械を作る問題のクラス。
●単純な製造品（simple workpieces）
テキストや画像などのデジタルデータを編集するツールを作成する問題のクラス。
●変換（transformation）
ある入力データを、求められる別の形式のデータに変換して出力する機械を作成する問題のクラス。
いわゆるビジネスアプリケーション、エンタープライズアプリケーションと呼ばれるようなアプリケーションが解決しようとする問題は、3番目の「情報表示」の問題に相当するといえるだろう。
しかし、デザインパターンは少し解決法に力点を置きすぎている。ある問題に対し、どうやれば効果的に解決できるかと悩んでいるときは非常に強力なツールとなるが、そもそも問題が何なのかを特定しようとしている段階、ソフトウェア開発の段階では「要求定義」と言われる段階においては、ほとんど力になってくれない。
その点では、Martin Fowlerの分析パターンもそう大差はない。分析パターンは、問題（あるいは世界）をどうやってオブジェクト指向に基づいて記述するか、を示したものである。世界は必ずしもオブジェクト指向のような単一の記法だけで表現できるものではない。例えば、太陽が昇るとともに小鳥たちがさえずる状況を記述するとき、太陽が小鳥たちにメッセージを送っている（あるいはメソッドを呼び出している）のでは決してない。また、それを差し引いても、分析パターンは「オブジェクトモデルを作る」という解決法の方に、やはり焦点を置きすぎている。
- マイケル・ジャクソン
- プロブレムフレーム ソフトウェア開発問題の分析と構造化
JSPやJSDなどの設計手法で知られるソフトウェア工学界の権威Michael Jacksonは、「問題フレーム（Probrem Frame）」という方法で、問題そのもののパターン化を試みている。Jacksonは、次の5つの基本的な問題フレームを挙げている。
●要求された振舞（required behaviour）
世界の中では、ある条件に応じてその一部の振舞が制御されなくてはならないことがある。この問題のクラスは、そうした制御を行なう機械（ソフトウェア）を作ること。
●命令された振舞（commanded behaviour）
オペレータの命令によって、世界の振舞が制御されるような状況がある。この問題のクラスは、そのような命令を受け取り、制御を行なう機械を作ること。
●情報表示（information display）
世界のある部分から、その状態などの情報を読み取り、適切な形で表示するような機械を作る問題のクラス。
●単純な製造品（simple workpieces）
テキストや画像などのデジタルデータを編集するツールを作成する問題のクラス。
●変換（transformation）
ある入力データを、求められる別の形式のデータに変換して出力する機械を作成する問題のクラス。
いわゆるビジネスアプリケーション、エンタープライズアプリケーションと呼ばれるようなアプリケーションが解決しようとする問題は、3番目の「情報表示」の問題に相当するといえるだろう。