UMLモデリングのエッセンス: 標準オブジェクトモデリング言語の適用 (ObjectTechnologySeries 4)

著者 : マーチン・ファウラー ケンドール・スコット

• 星雲社 (1999年1月1日発売)

感想・レビュー・書評

[Cognosce te ipsumさんの感想 · 2019年5月2日]

UMLの記法を習得するために有用。

[ichiro.marinersさんの感想 · 2018年10月23日]

ファウラーといえば、リファクタリングの開祖と呼ぶにふさわしいプログラマーだけに、この本の内容も非常によい。さすが、ファウラー。UML素人諸氏にはちょっとハードルが高いので、入門本を読んだ後、この本を読むのが良いでしょう。

[たこさんの感想 · 2011年12月3日]

マーチン・ファウラーの本を探していました。

UMLの説明と、ユースケース、クラス図、相互作用図、パッケージ図、状態図、アクティビティ図、配置図の説明、UMLでモデリングからプログラミングする例が載っています。
また、UMLだけでなく、UMLを使用したプロジェクトの進め方についての内容も含みます。

本書の一番の良いところは、「いつxxxxを使用するべきか」という説明が必ず載っていることです。（xxxにはクラス図やパッケージ図などがはいります。）世の中、UMLを知っている人は多けれど、どのように使用するべきかを知っている人は少ない気がします。

「いつxxxを使用するべきか」の部分だけでも、価値がある本です。ぜひUMLを使っている方にお勧めします。下に少し書きました。


以下は、自分の気になったポイントをメモります。

「プランニング」
予定工数以上の予定を組むことは絶対に避けるべきです。

「いつユースケースを使用するべきか」
設計者が違えば、ユースケースの使用方法も千差万別です。Jacobsonは、10人年プロジェクトに対して20ユースケース(使用関係と拡張関係を除く）が予想されているとしています。同じ規模の最新のプロジェクトで、私は100以上のユースケースを定義します。

「クラス図」「観点」
利用する上で重要となる微細なく別について説明します。「概念的観点」「仕様の観点」「実装の観点」がある。

「クラス図」「契約による設計」
事前条件は、操作を実行する前に、世界がどういう状態であると予期しているかを定義した文です。・・・事前条件によって、チェックのリスポンシビリティは呼び出し側にあることがはっきります。

「クラス図」「インターフェースと抽象クラス」
クライアントが見るのはインターフェースだけであり、その実装を見ることは絶対にないということです。

「クラス図」「拡張的概念」「参照オブジェクトと値オブジェクト」
通常、値オブジェクトに属性を使用し、参照オブジェクトに関連を使用します。

「相互作用図」「シーケンス図とコラボレーション図の比較」
多数の条件付き振る舞いを示すのに最もよい方法は何でしょうか？
これについての見解は、2派にわかれます。１つは、単一のシナリオに対して複数の独立した図を使う方法が最良だとする見解、もう一つは、メッセージに条件を使用して振る舞いを示す方法が最良だとする見解です。
私は、前者に賛成です。相互作用図は、振る舞いがシンプルであればこそ効果的なのです。振る舞いが複雑であれば、相互作用図はたちまち明快さをうしなっていまいます。複雑な振る舞いを1つの図で表現したいとき、私はアクティビティ図を使います。

「相互作用図」「いつ相互作用図を使用するべきか」
振る舞いを正確に定義する目的には不向きです。複数のユースケースに存在する1つのオブジェクトの振る舞いを見たいときは、ステートチャート図（状態図）を使います。複数のユースケースまたはスレッドにおける振る舞いをみたいときは、アクティビティ図がよいでしょう。

「パッケージ図」
「どうやって、1つのおおきなシステムを小さなシステムに分割するか」
その方法の1つ、構造化手法では、機能の分割が利用されてきました。・・・・その手法がよく使われていたのは、プロセスとデータが別個のものだったことのことです。そのため、機能の分割に加えて、データ構造というものも存在しており、これが2番目の位置を占めていました。(ちなみに、今は、機能もデータもなくなり、クラスとオブジェクトで分けている。)

「アクティビティ図」
フローチャートでは普通、順次処理しか扱えませんが、アクティビティ図では、並列処理も扱えます。

「訳者あとがき」
オブジェクト指向分析設計におけるモデリング上の心得を簡潔に、しかし重要なポイントはもれなく持ち運びに便利な小冊子にまとめることにあると発見されたことだろう。