| ||
|
モデルは実装非依存であるべき
開発プロセス上流工程で使われるモデルは，通常実装技術に依存しないことを前提とする。特定のOS，仮想マシンやフレームワーク，クラス・ライブラリ，アプリケーション・サーバー，Webサーバー，データベース・サーバーなどのプラットフォーム技術と，CGI，スクリプト言語，永続化メカニズムなどが規定するプログラミング・モデルから独立して定義される。こうすることで，複数の実装に対して同一のモデルを使うことが可能になる。
モデルを実装アーキテクチャへマッピングする作業は，実行可能なプログラムを作成する下流工程で初めて発生する。この段階で，モデル要素とソースコードをどのように対応付けるかを決定する（図2[拡大表示]）。
実装技術に依存しないモデルを作成することは，見積もりにも有効である。システム構築前のIT投資効果やコストの見積もりは，システム実装の詳細が確定する前に可能でなければならないからである。
モデルと実世界は乖離している
モデルはシステムを正しく表現するためのものであるが，必ずしも実世界の忠実な表現を目的としているわけではない。実世界で利用されるシステムを表現するための，便利な道具として扱うべきである。オブジェクト指向の世界観に立つならば，実世界はすべてオブジェクト（インスタンス）間の連携で記述される。しかし人間にとって，粒度と種類の異なる無数のオブジェクトを扱うことは困難である。このため，オブジェクトを共通の性質で分類し体系化する概念としてクラスを導入した。
モデルだけでなく，オブジェクト指向言語も実世界とは乖離している。オブジェクト指向言語の多くは，オブジェクトを生成するためのクラス定義を必須とする。これは開発言語が動作する上での決まりであり，実世界が必ずクラスを必要とするという意味ではない＊5。また一口に「クラス」と言っても，その意味が異なる場合があることにも注意が必要である。抽象レベルの異なるクラス，例えば，業務データモデルとオブジェクト指向言語のクラスとを同じ名前の箱で扱っていいのかと疑問を持つべきだろう。
仕様変更の許容度を高める
現在OMG（Object Management Group）が提案しているモデル駆動型の開発プロセスは，実装されるプログラムやデータ形式などのシステム表現と仕様とを独立させることで，実装戦略の自由度を持たせる。実装戦略の決定をできるだけ遅延させ，仕様変更によるプログラム変更の影響を減らすのである。つまり，仕様変更の許容期間が長くなる。これにより要件変化の激しいシステムの開発を可能とする。
ちなみに，モデル駆動型とは別の方法で仕様変更の自由度を高めようとする開発プロセスもある。代表的なのがXP（eXtreme Programming）である。XPでは，実装すべきプログラムの動作検証用のテストと必要最小限の機能を持つコードとを開発する。将来変更の可能性がある部分のコードをあえて書かないことで，仕様変更に許容度を持たせることができる。
ドメインクラス構築がポイント
では，実際にオブジェクト指向システムをモデル駆動型で開発する際にどのような点が重要になるかを整理してみよう。主要な技術上のポイントは4点に集約できる。（1）ドメイン分析/IT化の範囲決定/フィーチャの分析，(2)概念モデルの識別（マスター・データとトランザクション・データ），(3)ビジネスルールの発見と表現，(4)実装アーキテクチャへのマッピング，である。
まず最初に行う必要があるのがドメイン分析だ。コンピュータが実行する作業は実世界の中ではごく一部である。IT化すべき部分をどう定義するかによって，開発すべきシステムの姿，仕様は大きく変わる。この段階では，解決すべき問題のスコープ，作業の流れ，意思決定の手順と操作の選択肢，各作業の責任分担などを分析する。これを終えてから，要件定義として提供すべきフィーチャを抽出する。その後(2)の概念モデル（業務データ）や，(3)のビジネスルールを見つけ，モデルで表現する。
最後が，実装アーキテクチャを選択し，仕様をアーキテクチャ上で実装するという（4）の段階である。ここでは，ドメインクラス構築，リレーショナル・データベース設計，性能向上の開発コスト評価，クラス横断的なフィーチャやビジネスルールに関する保守性の評価が行われる。
中でも重要なのがドメインクラス構築である。ドメインクラスとは，業務処理のロジックを実装するクラスである＊6。それは，振る舞いと（概念）データを一体としたものとして作られる。業務プロセスの中で，複数の概念モデルのうちのどれに必要な処理（振る舞い）を割り当ててドメインクラスを構築するかを決定する必要がある。
例えば顧客が銀行口座の預金残高を照会する場合，照会操作をどの概念モデルに割り当てるべきかを考える。まず，候補となる概念モデルが何かを識別することが重要である。ここでは，顧客，銀行口座，取引の3種類を候補とすることにしよう。次に，照会操作を三つの概念モデルのうちのどの操作とするかを考える。顧客が持つ操作とするのは不適当である。同一の顧客が複数の役割を持つ場合にモデルが複雑になるからである。顧客は住宅ローンや給与振込みの契約者であったり，投信の購入をする投資家であったりする可能性がある。
ロールモデルを導入して，役割によって振る舞いを変えられるようにしてもよい。しかし残高照会に加えて，すべての役割に必要な操作は他にもある。これらをすべて顧客が持つのは顧客モデルの汎用性，他のアプリケーションでの再利用性を考えると好ましくない。
それより，銀行口座の方が望ましい。銀行口座に対する操作として，残高照会，預金引き出し，預け入れ，送金などの操作を持たせるのは自然である。銀行口座はそのための属性として，口座種別，口座番号，残高，開設日付などを持つだろう。
最後の取引に持たせるのは不自然だ。この概念モデルはマスターデータである顧客や銀行口座と異なり，トランザクション・データである。照会そのものの要求を表す。照会すべき口座番号，ユーザー名，照会実行時間などが入るはずである。このデータは銀行口座の持つべき照会操作に対する引数にするのが自然であろう。
このような分析の結果，概念モデルに対して操作が割り当てられ，ドメインクラスが構築される。概念モデルの適切なデータモデルに振る舞いを割り当てる一般化された作業と言ってもよい（図3[拡大表示]）。
ドメインクラスは，下流工程におけるオブジェクト指向言語のクラス定義やリレーショナル・データベースのストアド・プロシジャ実装の基本となる。このとき，ビジネスルールの問題は別途解決する必要がある。銀行口座残高照会は口座所有者からしかできない，照会可能な営業時間を限定するといったルールである。
