オブジェクト指向分析・設計において作成するモデルは，抽象度の違いに応じて3種類に分けられる注2）。抽象度の高い順に，「概念モデル」，「仕様モデル」，「実現モデル（実装モデル）」と呼ぶ。以下，順に説明していこう。
現在ではUMLを使ってオブジェクト指向分析・設計作業を進めることが一般的になりつつある。UMLで分析・設計内容を記述し，ユーザーとベンダー間，ベンダー内の設計チームと開発チーム間などで共有すると，システムの姿を明確にし，あいまいさを排除できるからだ。
概念モデルは，主に業務分析のために作成する。要件の記述や仕様定義の際の共通コンセプト，システム化する業務に登場する基本的な語彙をまとめたものだ。概念モデルとしてUMLで作成するのは，クラスの内容と関係を記述する「クラス図」と，大まかな業務の流れを記述する「アクティビティ図」である。
ただし，概念モデルにおけるクラス図には具体的なメソッドやプロパティは記述しない。概念モデルは，顧客と開発者の両方が参照するモデルだからだ。この意味で概念モデルの役割は，要件定義段階で作成する「ユースケース図」と対になっている。
徐々に実装に近づける
2つ目のモデルである「仕様モデル」は，顧客の要件をシステムとして実現する際に，どのような機能を持つオブジェクトを開発すればよいか，オブジェクト同士をどのように連携させるかを定めたものだ。これはすなわち，クラスの「インタフェース」を定義することにほかならない。
この仕様モデルとしてもクラス図を作成する。ここで読者は，「概念モデルでも仕様モデルでも，同じクラス図を作成するのか？」という疑問を持つかもしれない。しかし当然ながら，同じクラス図といっても内容は異なる。内容の“深み”が違うのだ。
概念モデルとして作成するクラス図は，顧客と開発者が参照するので，顧客の業務の中で使われている語彙を使って記述する。これに対して仕様モデルとしてのクラス図は，各クラスが備えるべき具体的なプロパティやメソッドを記述する。仕様モデルは顧客に見せるものではなく，開発チームの中で設計担当者とコーディング担当者が，意思の疎通を図るために参照するためのものだからだ。
3つ目の「実現モデル」は，仕様モデルで設定した各クラスを，個々のプログラミング言語やミドルウエアで実装するためのモデルである。
実現モデルとして作成するクラス図は，仕様モデルにおけるそれより，さらに実装を意識した内容になる。具体的には，プロパティやメソッドの記述法をプログラミング言語の文法に沿って修正したり，利用する「フレームワーク」に応じてメソッドやクラスそのものを追加したりする。このようにモデルの内容を徐々に実装レベルへ近づけていくことで，開発作業をスムーズに進めることができる。
3つの視点でモデルを作成
 表1 オブジェクト指向開発の反復サイクルにおける3つの視点 [画像のクリックで拡大表示] |
 図2 ユースケースとモデリングをつなぐロバストネス分析 要件定義で作成したユースケースごとに，分析-設計-実装というサイクルで作業を進める [画像のクリックで拡大表示] |
次に，概念モデル，仕様モデル，実現モデルを，分析・設計作業のどのタイミングで作成するのかを見ていこう。
一般的に，オブジェクト指向分析・設計は，ユースケースごとに「分析—設計—実装」という3つの視点で，モデリングを繰り返す（表1[拡大表示]，図2[拡大表示]参照）。先ほどの3つのモデルは，この各視点に対応する。分析視点では，ユースケース図を基に適切なオブジェクトを抽出し，それらの関係を定義する作業を行う。ここで作成するのが概念モデルである。
設計視点では，仕様モデルを作成する。分析視点で作成した概念モデルに基づき，情報システムに実装するために必要なメソッドや属性を定義するのである。具体的には，ある処理を実行するにはどのオブジェクト同士が連携すればよいかという処理の順序や，オブジェクトの状態遷移などを決めていく。
3つ目の実装視点では文字通りコーディングを行う。実現モデルは，その設計指針を示すのに作成する。
反復スタイルで手戻りを減らす
注意してほしいのは，「分析—設計—実装」の各反復サイクルにおける作業は，一方通行ではなく行きつ戻りつして進めていくということだ。
現実のソフトウエア開発は，一方通行で進むことはまれだ。開発するシステムの規模が大きくなったり，新たに機能を追加するなど，常に設計仕様の変更を余儀なくされるリスクを抱えている。設計内容の不備に気づいた場合には，前段階に戻って修正したい場合もあるだろう。
例えば分析視点で作成する概念モデルは，ユースケース図と密接な関係があり，両者は相互に内容を反映させながら徐々に完成形に近づいていく。例えば，ユースケースの「粒度」（システム化すべき機能の単位）がうまくそろっていない場合には，いったんユースケース図を修正して，変更内容を概念モデルに反映させる。また概念モデルを作成する過程で，要件の不足や誤りに気づいた場合は，不足している要件をユースケースに追加する。
なお，ユースケース図に記述してあるユースケースを，どういう順番で開発していくかは，業務上の優先度やリスクの大きさ，アーキテクチャへの依存度などを考慮して決めていくのが基本だ。もちろん，複数のユースケースに属する重要な共通オブジェクトに関しては，反復サイクル注3）をいくつか並行して設計・実装するというやり方もあり得る。杓子定規に反復を繰り返すのではなく，あくまで柔軟に開発を進めるのが重要だ。
以上，簡単ではあるがオブジェクト指向分析・設計において作成するモデルの概要と，作成作業の基本的な流れを説明した。オブジェクト指向分析・設計には経験と慣れが必要で，それを手に入れるためには，楽しみながら日常生活を含むさまざまな対象領域をモデリングしてみることをお勧めする。
