設計におけるデザインパターンを、ビジネスプロセスのモデル化に応用したもの。前半は、具体的な事例をモデルとして表すことで、モデル化の実用性を示そうとしている。2002年の書だが、ビジネスプロセスモデリングの走りだろうか？後半は、もう少し抽象的な形で、方法論を解説し、様々なビジネスをモデリングできるよう支援してくれている。

前半の7割は、医療系や勘定系ソフトのデザインパターンについて深い考察の展開。医療系や勘定系の処理について全くの素人（私も）には、理解するのにかなり骨が折れるが、ファウラーの分析手順がよく分かるという意味で、意義深い。残りの3割は、デザインパターンで作られたモデルを言語に落としていくときのさまざまな問題点についての考察。これもなかなか良い。ただ、全体について情報が古く、またモデルを表現するのにUMLではなく彼独自の記法が使われていることが残念である。

p2. 「モデリングの原則　モデルは正しいか誤っているかではなく、使いやすいか、使いにくいかである」 言語が、正しいか誤っているかよりも、分かるか分からないかの方が大事であることに似ているような気がした。 言語で表現したものが、モデルであると考えれば、相似な意味があることが分かるかもしれない。 モデルは、現実のある部分を相似に表現したものだから。 modelは型で、patternは原型。モデルを少し具体的にしたものがpattern。 ２章の責任関係は、仕事をする上で大事なもの。 制約(constraints)が初めのうちから出てくるのがこの本のよいところ。 制約を書かなくては型の範囲、機能が分からない。 よく、要求(requirements)が大事というが、制約の方がより厳密。 要求(requirements)を書く前に、制約が分かっていれば安心。 制約がわかっていなければ、要求を調べる中で、制約が何かを特定するとよい。責任は要求ではなく制約として記載した方がよいことが多いかも。 制約、要求を明確にする際にHAZOPという手法を使っている。 ３章の観測と測定も大事。モデルの中で観測するのが、モデルの外で測定するのかが大切。モデルの中で測定していると、モデルに影響を与えることが記述できる。 社会事象は対象に影響を与えずに測定できないということが原則。 大事なことが初めから議論できる題材があるのがこの本のよいところ、 ４章は企業財務の観測。原価計算が仕事の基本。費用(cost)を問題にする際に、「原価計算をしていない」という馬鹿な話にしばしば出会うことがある。原価計算をしていることを知らないだけかもしれないのに。観測そのものを知らない可能性があるので、振り出しに戻ってもらうといいかもしれない。時系列図(sequence chart)がここで出てくるのもいい感じかも。 ６章が在庫管理と会計になっているのもよいかも。 在庫管理はコンピュータで処理するのに適した題材の一つ。 ７章が会計モデル。ここまで来れば、仕事が始められる。 ８章計画、９章トレーディング。 １０章デリバティブ（金融派生商品）ここの怪しさがわかれば一人前かも。 ps. 児玉公信さんが翻訳されているので手に取りました。 これまで２度手に取ったことがあります。 １度は、出版された頃。 ２度目は、UMLの講師をするために。 ３度目は、技術士の方がかかれた本または翻訳された本を読むために。