オブジェクト指向分析・設計の基本は，適切な「モデル」を作成することである。ここではオブジェクト指向に基づいた分析・設計手法の難しさを述べるとともに，具体的なモデルの内容，作成手順を解説する。オブジェクト指向では「分析−設計−実装」を反復することで開発を進める。
近年のオブジェクト指向の広がりには，目を見張るものがある。例えばオブジェクト指向の分析・設計モデルを作成する「UML（Unified Modeling Language）」の解説書や雑誌の記事は，今や世にあふれている。加えてUMLによる分析・設計スキルを認定する資格が登場するなど，オブジェクト指向の認知度は確実に向上していると言えよう。
しかし，オブジェクト指向関連製品や技術がこれだけ普及しているのとは裏腹に，その基本原理であるはずのオブジェクト指向分析・設計技法が正しく実践されているとは言えない。UMLとJavaを使ってシステムを開発したものの，オブジェクト指向に沿った設計になっていなかったり，クラスなどの部品の再利用が進まず，システム開発の効率性が高まらないという状況も見聞きする。
こうした事態を回避するには，オブジェクト指向分析・設計の基礎を丁寧に学ぶことが結局は早道である。
難しさは「自由度の高さ」
まず「オブジェクト指向分析・設計」とはどのような作業なのかを，きちんと定義しておこう。オブジェクト指向「分析」とは，システム化すべき業務から，適切なオブジェクトとオブジェクト間の関係を抽出してくること。その結果を基に，システムの適切な構造と，オブジェクトの役割や振る舞いを定義していくことがオブジェクト指向「設計」だ。
このように口で言うのは簡単だが，一般的にはオブジェクト指向で適切なオブジェクトを抽出したり，設計するのは難しい。オブジェクト指向分析・設計が容易な作業でないことは，事実である。
なぜ難しいのかを一口で言うと，「自由度が高すぎるから」ということになる（図1[拡大表示]）。そもそもソフトウエアには形がない。何をどう設計するかは，分析・設計者の自由だし，観点によってできあがるものがまったく異なってしまう。
では，どうすればよいのか。自由度が高すぎるのであれば，その自由度を狭めればよい。つまり分析・設計作業を一貫した視点で進められるように，適切な制約を課すのが解決策ということになる。
すべてを「モデル中心」で
この制約を課すための手法が，「モデリング」にほかならない。対象業務をある視点で分析し，各種のモデルを作り，それを基に開発作業を進めるのである。
システムの分析・設計に関する情報を，すべてモデルとして表現・管理注1）することは，オブジェクト指向分析・設計の大原則と言える。顧客と開発者との間で議論をする際にあいまいさを排除し，意識を共有するためには，ユーザーの要件やシステムの構造などを図式化したモデルを作成するのが最適だからだ。
この考えの下にオブジェクト指向分析・設計では，顧客の要件はもちろん，プログラムのソースコードもモデルと対応付けて管理し，相互の整合性を維持するのである。開発工程の途中で管理すべき項目が新たに発生したら，それはモデル中のどこに位置付けるべきかをまず検討する。
オブジェクト間の協調を分析
モデリングの前提となる重要な作業が「ロバストネス分析」である。一般的に，オブジェクト指向分析・設計は，まず要件定義の段階でユースケース図を作成する。ユースケースとは，利用者から見たサービスを，システムがいかに提供するかを記述したもの。これらのユースケースをシステムとして実現するには，ユースケースを複数のオブジェクトの協調作業に置き換えなければならない。そこで，ユースケースごとにロバストネス分析を行った結果の図（ロバストネス図）を使って，オブジェクト間の役割分担を検討する（図2[拡大表示]）。
ロバストネス分析では3種類のオブジェクトを使って，オブジェクトの協調作業を表現する。外部アクター（システム外オブジェクト）とシステム内オブジェクトのインタフェースを受け持つ「バウンダリ」，そのユースケースの基本的な業務ロジックや制御フローを管理する「コントローラ」，業務領域の情報を使って業務を実行する「ドメイン（エンティティともいう）」である。
このロバストネス分析の結果を基に，具体的なモデリング作業に入っていく。いわばロバストネス分析は，モデル（システム）とユースケース（業務）をつなぐための作業と言える。
これにより「分析と設計」，そして「ユースケースとオブジェクト」の間の大きな溝を飛び越えることができる。その意味で，ロバストネス分析は分析・設計モデリングの肝である。
