［『UMLモデリングのエッセンス』の一番搾り］
編集長より「UMLモデリングのエッセンス」の内容を消化せよじゃなかった紹介せよとの厳命が下りました。エッセンスなんだからもうこれ以上絞り出すことはできませんといいますと、そうかそれはよい、ではタイトルは「エッセンス++」でいこうと反論されます。それは変です、それではエッセンスが煮詰まるどころかC++のように薄められてしまいます、などとやり合っているうちに「エッセンス↑2(自乗)」ということになりました。
ちなみに、本物の「はじめに」では、UMLスリー･アミーゴと呼ばれるBooch, Rumbaugh, Jacobsonからの推薦の辞が述べられています。
|
この本にあまりに期待してはいけません。この本がどういう書籍では「ない」かが『まえがき』に3項目に渡って規定されています。怒りっぽい人、早とちりの人はぜひここを読んでから本書を購入しても遅くはありません。
|
ここでは、UMLスリー･アミーゴに対する謝辞が書かれています。スリーアミーゴって意訳すると「三羽烏」「三銃士」「三馬鹿トリオ」ってことですね。まぁ、素直に「三人組」というところでしょうか。ちなみに、例のデザインパターンを出版したGang
Of Fourの面々は「四人組」と訳されています（というか私が勝手にそう呼んで普及活動してます）。実際、英語圏ではGang
Of Fourといえば、中国の文化大革命当時の江青ら4人組のことを指しますから、それを意識しているはずです。
また、Jim Odell氏にも感謝をしています。実は、彼は、UML統一の影の功労者です。また、Fowler氏はかなりOdell流のモデリング技法を高く評価していて、エッセンスの本なのにもかかわらず「動的分類」や「多重分類」を取り上げています。
|
方法論者とテロリストの違いを知らない純な人はとりあえずこの章も読んだ方がよいでしょう。またUML成立の舞台裏について知りたいという不純な動機の人も読むと獲るところがあるかも知れません。
|
この章にはUMLのことは何も書かれていませんが、本書のハイライト、エッセンス、牛タン、豚のシッポとでもいうべき最重要な部分です。この章を読むためだけでも、定価\2,400は異常に安いでしょう。ここでは、Fowler氏が自分流に再解釈したObjectory(ないしはUnified Process)法の核心部分を非常に手際よく、しかし実際的なノウハウも交えて紹介しています。開発エンジニアはもとより、プロジェクトマネージャ、管理者すべての人にぜひ目を通して頂きたいと思います。
また、ドメインモデリングとユースケースの相補的な役割を強調しているのも非常に好感が持てます。ちょっと実践でユースケースを使ってみればわかることですが、ユースケースだけをベースにモデリングを進めていくとオブジェクトモデルが歪んでしまう傾向があります。
また『「モデリングフェーズ」はいつ終了するのか』という質問に皆さんはどう答えますか。「分析をどのタイミングで止めて設計に移行すればよいのでしょうか」というのも同じ事です。OO開発に付きまとうこの本質的な問いに対するFowler流の現実的な解答を知りたい人も本書が読みたくなることでしょう。困りましたねぇ。
あと最後にひとつ、繰り返し型の開発はどんなときに適用すべきか、というよく聞かれる質問への本質的かつ論理的な解答が用意されています（＊この解答は、この文章の末尾に付けておきますので、そこにたどり着くまでに考えておいてください）。
|
ここでは、ユースケースの要点が簡潔に書かれていますが、この記述だけではユースケースは使いこなせないでしょう。Jacobsonらの「オブジェクト指向ソフトウェア工学OOSE」(トッパン、1995)や最近出たSchneiderらの「Applying
Use Cases -- a Practical Guide」(Addison-Wesley、1998)を用いて、ユースケースの粒度の設定やユースケース記述のノウハウについては補う必要があるでしょう。
そうはいっても、アクターや外部システムの扱い方については参考になります。
|
「訳者後書き」でも述べましたが、「概念モデル、仕様モデル、実装モデル」という３つの視点の区別の導入がここでのもっとも重要なポイントです。
またより上級のモデリング能力をめざす人は、リスポンシビリティとインターフェースの区別、「観測可能状態」の概念とクエリ/更新操作の関係、汎化関係を理論的に定義するためのLiskovの置換原理、そしてEiffelの設計者バートランド・マイヤーの提唱する「契約による設計」概念、などなどを少しずつ習得していくとよいでしょう。こんな薄い本なのに、なぜか道は遠いですねぇ、気のせいです。
|
この章は上級編です。第4章の内容でクラス図の90%は尽きています。それらをきちんと学んだ上で挑戦しましょう。UMLで初めて導入されたステレオタイプ概念の紹介がさらっとあった後、Odellの導入した多重クラス分類、動的クラス分類をモデリングにどう活かすかが述べられています。現在のオブジェクト指向言語でこれらの概念を直接的に実装できないという問題もあってあまりモデリングに適用されていませんが、問題ドメインの自然な記述に役立つのであればどんどん使おうというのがFowlerの基本スタンスです。
また、参照オブジェクトと値オブジェクト、変更不可性と「frozen(凍結)」制約についても通常より詳しい解説があり参考になります。
また、たぶん、みなさんの半数以上は「関連クラス」のセマンティクスを誤解していると経験上いえますので、この際、きちんと本書で関連クラスとはどういうものなのか基本からマスターするのも一興;-)かと存じます。このセマンティクスの違いがないと、無理に関連クラスなどといって通常のクラスと異なるモデル要素をUMLが導入している意味がなくなってしまいますからね(ここで何が言われているのかわからなくても心配御無用。本書のp.
78-81をしっかりと読みましょう)。
|
この章にはそれほど目新しいことは書かれていませんので、シーケンス図とコラボレーション図の基本を習得している人は読む必要はないでしょう。
|
まず最新のUMLでは、「パッケージ図」というダイアグラム種の呼び名は用いていません。あくまでも、このタイプの図はクラス図のバリエーションという位置づけだということに気を付けてください。それを踏まえた上で、Fowlerがなぜ敢えて「パッケージ図」という章立てを用意したかを理解する必要があります。さぁ、なぜでしょう。
現在のUMLでは、モデルの全体構成を表現する目的の図がありません。クラス図やコンポーネント図をそういう目的にも使えるよ、というレベルです。しかし、どんな場合にも、あるプロジェクトでモデル全体をきちんと管理することは必須であり、その重要性を強調するために敢えて「パッケージ図」という独立したダイアグラムの種類を識別していると理解すべきでしょう。これによって、概念的なアーキテクチャを表現することになります。
また、細かい点ですが、<<imports>>と<<includes>>のセマンティクスの違いにも気を付けて依存関係を定義する必要を指摘している点も重要です。
|
この章ではあまり突っ込んだ議論はなされていません。他の本(たとえば、OMT本など)で補う必要があるでしょう。
やはりFowler氏はどちらかというとビジネス系のシステムが得意だからでしょう。制御系・リアルタイム系・組込み系のシステムをモデル化する際には、ステートチャート図は本質的なモデル要素です。
|
「アクティビティ図は、最もUMLらしくない部分です。」と冒頭で述べておきながら、本書でもっとも力の入った記述がなされている部分です。Odelのイベントスキーマ図やペトリネット記法の影響を受けた記法ですが、基本的には個々のオブジェクトを超えた範囲での状態遷移図の応用と考えることができます。
アクティビティ図はオブジェクト指向ではありません。そのためこの図を毛嫌いする人も多いようです。しかし、この世の中はオブジェクト指向でできているわけではありませんから、問題領域の大局的な振る舞い、企業活動の様子、業務フローといった対象をモデル化するためには、「モノ」ではなく「アクティビティ」とそれらの間の依存関係や推移関係を記述できる枠組みがどうしても必要になります。これらのアクティビティを「誰」にやらせるか（どの組織、担当、個人といったオブジェクトのリスポンシビリティとして割当てるか。この部分はUMLでは「レーン」を使うこともできますが）を考えることは、ある種の（BPR的な）設計に踏み込んでしまうことになるからです。
そういう意味で、モデリングの上流ではユースケースと併せてアクティビティモデリングとドメインモデリングを行なう重要性がここでは強調されているのです。オブジェクト指向で何でもモデリングできると考えているそこのナイーブなあなた、ぜひこの章を読んで自分なりに業務のモデリングはどうあるべきなのか考え始める端緒にしてください。
|
非常にあっさりと2ページで書かれていますが、ぜひここで使われている図10-1をじっくりと味わってください。そして、コンポーネントとは何か、それはパッケージ図で言うと何にあたるのだろう、配置図での依存関係は何を表わしているのだろうとと自問してみてください。配置図は、パッケージ図が概念アーキテクチャを表わすのに対して、物理アーキテクチャを表わしています。そう考えると、Fowler氏が現在のUMLの慣行に敢えて逆らって「パッケージ図」というダイアグラム名を陽に出す理由もおわかりでしょう。
|
Javaを用いて、ヘルスケアの問題領域に関して、概念モデリングから仕様モデルを経ていかにプログラミングレベルに到達するかという１つの例をサンプルとして提示しています。しかし、ユースケースやアクティビティを用いた業務モデリングが全面カットされ、アーキテクチャレベルの議論もほとんどなされていないので、せっかくの第2章の内容との繋がりがよく見えてこないと感じられる読者も多いことでしょう。ぜひ、同じ著者の「アナリシスパターン」(トッパン、1998)等を読んで補いましょう。
|
以上、急ぎ足でこの名著「UMLモデリングのエッセンス」の名所案内をしてきましたが、いかがでしたでしょうか。なんだかエッセンス↑2 でなく、エッセンス++ になってしまったのではないかと危惧します。ともあれ重要なことは、書物はあくまでも書物に過ぎないということです。あまり期待し過ぎるのは禁物です。その前提の上で、上手に自分自身にとってのエッセンスを栄養分として消化してください。そして、その栄養分が次の実プロジェクトのメンバーによって消化されていくことになるわけです。実践しながら考えましょう。経験しながら改善しましょう。学びながら教えましょう。輪廻ですか。縁起ですか。そんなことをいうひともいますがね。まぁ、ともあれ、よいご旅行を。
(＊)繰り返し開発は、成功させたいプロジェクトにのみ適用するべきですJ (p.34)
| © 1999 OGIS-RI Co., Ltd. |
|
