今日、ソフトウェア開発者達は慌しいプロジェクトに追われ、適切なモデルのための時間にしく、失望した現実に直面している。UMLが広範囲に渡って認められるようになったのも、忙しさの余り正しいモデリングの習得が困難で、不完全なままだったからであろう。本書では、UMLモデリングへのアプローチに関する記載事項をコンパクトにし、解りやすいユースケースを使っているので、図の作成やテクニックを敏速かつ能率的に習得する事が出来るでしょう。

本書では、詳細設計やコーディング等のユーザ必須項目をたどりながら、開発者の皆様へ最小限の時間でUMLモデルを解説する実用的なガイダンスを提供しています。とても解りやすいユースケースを用いて、著者達の豊富な経験が生んだ折り紙付きの方法で、オブジェクトモデリング作業がスムーズに出来るでしょう。.

＜本書のハイライト＞
・本書を通して展開する、明解かつ解りやすく統合された例題。
・ 各章での最重要ポイントを要約した“トップ１０リスト”。
・ UMLモデリングにおける落とし穴を回避する為の“分析注意点”。
・広範囲に及ぶ必要条件の定義とトレース法からの設計。
・モデリングを完成させるまでに、差し当たり必要と思われない理論は省略。
・効率良く作業を進めるためのビジュアルモデリングツールを拡張する、実用的なヒント集。

ダグ・ローゼンバーグ：ICONIXの創設者、兼社長。UMLが考案される数年前でもある、１９９２年よりヤコブソン／ブーチ／ランボーの統一手法を教え続けてきた。彼が手掛け絶賛されたCD-ROMチュートリアルには、“Complete CORBA”、“Mastering UML with Rational Rose”、“A Unified Object Modeling Approach”等がそれぞれ収録されており、４０ヶ国以上もの国々で広く使われている。これまでにもボーイング社をはじめとする、デューク・パワー、ヒューズ、JCペニー、ロッキード・マーチン、ルーセント、モトローラ、NASA、フィリップ・モリス等、数十もの会社にUMLを使ったオブジェクトモデリングを教授してきた経歴も持つ。それに加え、オブジェクト・マガジンやソフトウェア・ディベロップメント、ローズ・アーキテクト等の出版物へ数多くの記事を出稿してきている。

ケンドール・スコット：受賞した「UML Distilled（UMLモデリングエッセンス）」の著者であり、金融や会計関連ソフトの専門的なライター。ソフトウェア・ドキュメンテーション・ウィザード（SDW）の校長。

目次

はじめに

第一章：ICONIX統一オブジェクトモデリングのアプローチ
背景
アプローチへの第一歩
方法論について
基本的プロセス
簡潔なアプローチ

第二章　ドメインモデリング
クラスを発見
汎化関係の構築
クラス間の関連作成
関連クラスの設計
ドメインクラスの文書は宝
分析クラス図の作成
繰り返しと洗練の継続

第三章　ユースケースモデリング
ユースケース、アクタ、ユースケース図
分析段階と設計段階におけるユースケース
ユースケースの作成
ユースケースを特定するためのGUI内部の設計
ユースケースのユーザマニュアルマイニング
ユースケースと条件の洗練
アクションの基本作用・相互作用
共通機能の抽出
UMLやOMLでの構築
実例の復習
ユースケースのパッケージ
ユースケースと条件
ユースケースモデリングのまとめ

第四章　分析
分析の主要な役割
サニティチェック
完全性チェック
オブジェクトの発見
予備設計
分析オブジェクトタイプについての詳細
分析の機能
ドメイン（静的）モデルの更新
分析のまとめ

第五章　相互作用モデリング
相互作用モデリングの目標
シーケンス図
シーケンス図の実際
クラスにメソッドの追加
実例
静的モデルの更新
属性とメソッドの最終決定
品質確認
インフラの付加
設計のパターン化
実例の復習
相互作用モデリングの完成

第六章　コラボレーションとステートモデル
コラボレーション図が必要な場合
ステートチャート図
ステートチャート図が必要な場合
アクティビティ図
相互作用モデリングの拡張

第七章　要求仕様の整理
要求仕様とは何か
要求仕様とユースケースと関数の性質
要求仕様のトレース
要求仕様を満たすためのビジュアルモデリングツールの拡張
要求仕様とICONIXアプローチ
コーディングへの準備

第八章　実装
プロジェクトスタッフの問題点
プロジェクト管理
静的モデルの見直し
クラスを配置したコンポーネント化
コードヘッダ
テスト
メトリクス
ユースケースドリブン開発の追跡
まとめ


付録：ユース対拡張
参考文献
索引

序章

本書は以下のような読者を想定して書かれています。

・最終的にはコードを書きたいが、その前にオブジェクト指向分析／設計をUMLで正確に表記したい。
・プロジェクトの期間中に納期を守って納品がしたい。
・ユーザの要求を満たすコードにしたい（つまり、ユースケース駆動でモデリング手法としたい）。
・コードを構造化するためのオブジェクト指向アーキテクチャを、柔軟で持続性があり、なおかつ強固なものにしたい。

本書は、さまざまなプロジェクトで有効性が証明されているアプローチを使い、可能な限り効率の良い方法で、読者が以下の図のポイントA（ユースケース）から、ポイントB（コード）へとたどり着く手助けになることを目的として書かれています。

→図　どのようにユースケースからコードへたどり着くか
　　　ユースケースモデル　→　コード


理論 対 実践
　
理論と実践の間には、理屈の上では何の相違もありません。

もっと具体的に言えば、原書の副題が「実践的なアプローチ」となっている理由は、「スリーアミーゴ」（Grady Booch、Jim Rumbaugh、Ivar Jacobson）が、（本書の執筆時には）最新の執書である「Unified Modeling Language User Guide[Prentice Hall,1993]、邦訳：統一モデリング言語ユーザーズガイド」の中で、何をもってオブジェクト指向理論に達するかについて書いているからです。

このことについて説明しましょう。

ソフトウェア開発の冷たく厳しい現実において、モデリングに費やせる時間は決して十分にはありません。UMLは一般的に、与えられた開発の側面を記述する方法として3種類の方法を提供していますが、プロジェクトのスケジュールにおいて３種類の方法を使う余裕などないため、1つ以上の方法を採用することは非現実的とされています。さらに悪いことに、UMLと他の表記法とどちらを使用するかを決定すること自体が信じられないくらい時間の無駄なのです。

そこで本書では、UMLが提供するすべての手法を利用せずに、シンプルな考え方を提案しています。アクティビティ図、配置図、ユースケース協調図、マルチレベルステートチャート図、さらにタイプやロールについては本書ではまったく、もしくはあまり詳細まで触れていません。むしろ、最小限の図と技術を用いて、読者がユースケースからコードへと「迅速」で「効率良く」たどり着けるように、「合理化された」ソフトウェア開発へのアプローチを紹介しています。読者が、UMLの他の手法が便利だと思えば、いつでもそちらに切り替えればいいのです。本書のアプローチは柔軟でオープンです。

作業を簡単にするためにUMLを拡張して使っています。そのことに対して謝罪するつもりはありません。なぜならば、UMLは拡張されるために設計されており、正当なことだからです。本書で提唱している拡張によって、時間が短縮され、費用が節減され、かつ良い結果が得られています。幅広い業種のいくつものプロジェクトで、数年にわたり指導してきた経験の結果が良好なことが、この発言の裏付けになっています。


本書の構成

本書は、8つの章で構成されています。目指す最終目的地（もちろんコード）から、作業をさかのぼってみましょう。
コードを得るために第八章「実装」では、属性とメソッドを持った完全なクラスのセットが必要です。 

第六章「協調図とステートチャート図」では、オプションになる協調図やステートチャート図について、第七章「要求の考察」ではプロジェクトをとおしての要求にどのように対応するか、について解説しています。

シーケンス図（第五章「相互作用モデリング」）を記述することによって、どのクラスがどのメソッドの責任を持つかを適切に判断できます。したがって、全てのユースケースに対してシーケンス図が必要です。この時点でメソッドをクラスに割り当てていくのです。

ユースケースに対してシーケンス図を記述する以前に、どのオブジェクトがどのユースケースに働きかけるか、ユーザアクションの結果としてシステムはどの機能を実行するか、ということを十分に理解しておく必要があります。これは、第四章「ロバストネス分析」から導き出されたロバストネス図で理解できます。ロバストネス図を描くことで、新しいオブジェクトを発見でき、またクラスに新たな属性を付け加えていくことができるのです。

また、ロバストネス図を記述する前にはオブジェクトモデルのコンテキストにおけるシステムの使用方法について記述しておく必要があります。つまり、第三章「ユースケースモデリング」のガイドラインにそって、ユースケース記述書を書かなくてはならないということです。さらに、「境界オブジェクト」はどれか、新システムとの接点となる「アクタ」はどれか、特別なケースでの振る舞いは何か、といったことを明確にする必要があります。このようにしながら新しいオブジェクトを識別していきます。

ユースケース記述書を書く以前に、問題領域に存在する主な抽象物を特定する必要があります。つまり、ドメインモデルが必要なのです。これを第二章「ドメインモデリング」で解説しています

第一章「ICONIX統一オブジェクトモデリングのアプローチ」では、全体をとおしてのアプローチについて説明しています。

本書では例として、有価証券取引と経理システムを使用しています。この例に関するRational Roseモデルは、http://iconixsw.com/BooksExample.htmlで見ることができます。

オブジェクト指向において、本書がユニークな書籍とされる2つの特徴を以下に挙げます。

・「TOP10リスト」を第一章以降それぞれの章の最後に記載しています。これは、その章で説明したポイントを要約したもので、繰り返し参照できる便利なリストです。
・本文のいたる所に、「分析中毒（Analysis paralysis）」の警告をしています。
これは、いかに簡単にソフトウェア開発中、非生産的な行為に陥ってしまうかを警告したものです。

もう1つ付け加えるとすれば、本書はおもしろいことは言うまでもありませんが、ほとんどのオブジェクト指向の書籍より楽しく読めるでしょう。

謝辞

本書は、私（Doug Rosenberg）の視点から書かれていますが、そのほとんどはKendall Scottによって書かれたものです。言い換えると、読者が本書で気にいらないと思う部分は彼の責任であり、それ以外全部（つまり、本書の良い部分の全て）は、私の責任です。

他人が自分の代わりに執筆するという経験を読者がお持ちでないとすると、（おそらく、お持ちでないでしょうが）このようなプロセスは「本当に私がそんなことを言ったのか。」と自分に対して文句を言う面白い体験でした。私からのアドバイスがあるとすれば、読者のみなさんがKendallのような優秀な作家と一緒に仕事をする機会がないのであれば、本を書くことは試みないほうがいいでしょう（でもとりあえず、Kendallに電話をかけてみるとよいでしょう。私達は、本書を書く作業をとても楽しんだので、他人にもするように薦めています）。

本書のほとんどは、Eメールを利用して書かれています。本書を書いている初期段階で幸運にも私達は、お互いに似たようなユーモアのセンスを持っていることに気付き、さらにラッキーなことに、2人以外の誰も本書の原形となった長いチェーンメールを見ることがなかったということです（少なくとも私達は、マイクロソフトの独占禁止法訴訟から、1つのことを学んだということです）。

ともかく、この２人のコンビがどんな奇妙でユニークな反応を引き起こしたとしても、私たちはその結果として、読者が本書を楽しく読むことができ、本書の有効性を見出すことを願っています。

当然本書は、「スリーアミーゴ」の功績、特に、スウェーデンでオブジェクト指向分析と設計についてステップ・バイ・ステップでのアプローチを確立したIvar Jacobsonたちの功績がなければ、本書の存在はあり得ません。私は、「新しく改良されたビジネスの方法」が錯乱する中で、この功績が決して失われてしまわないことを切に願います。

以下の評論家に感謝します。
・ Perry Cole（MCI WorldCom）
・ Steve Ash
・ Jom Conallen （Clarity）
・ Joel Erickson （Litton Guidance and Control System）

また、過去アメリカ各地で開催されたトレーニングワークショップ中に私達の進行中の仕事を批評してくれた人たち（特にお名前をあげないがこれでお分かりになるだろう）に感謝します。

次にKを頭文字に持つ3人、Addison-WesleyのKristin Erickson、 Krysia Bebick 、Carter- Shanklin （頭文字はKではないのですが、発音がKなので名誉をたたえて）に感謝します。

さらに、図や注釈の作成を手助けしてくれたLucy Guerrero 、Alex Polack 、Cliff -Sadlerに感謝します。

最後に、シンプルで分りやすい方法でOOA&DとUMLモデリングを提唱することの必要性を強く認識させてくれたBob Martinに感謝します。彼が本書を書くインスピレーションを与えてくれました。