概念モデルの再考
ソフトウェアは概念、論理、物理レベルで定義されます。もっとも論理と物理レベルの境界の曖昧性から、概念（ビジネス、what）と論理/物理（IT技術、how）で分類する場合もあります。
いずれにしても概念レベルでソフトウェアがカバーする範囲、コンテキストを明確化することが大切です。従来の概念レベルでの定義は、概念モデルと呼ばれるモデルで、ビジネスの仕組み（ビジネスアーキテクチャ）、知識とその体系化を示すことが中心でした（これ以外にビジネスプロセスなどの動的記述もありますが）。しかし、この定義をベースとしたソフトウェア開発は概念と論理レベルの間に深いギャップがあるため、概念モデルは仕様というには抽象的過ぎました。この抽象的という意味には、
- 概念モデル（そのモデル要素）とその実現技術との関連性が直接的に理解しにくいという意味
- 概念モデルの表現の実現にはステークホルダーの関心の違いがあり一意に決まらないという意味
があるように思えます。1は実現技術の選択肢が無数にあり、プラットフォームや非機能要求、プロジェクトの持つ制約（納期、コスト、開発者のスキルなど）が前提とならないと決められないことです。また、2は概念モデルのビューに相当し、ステークホルダーが持つ価値観、要求の相違により、実現する場合にどの部分が優先され、どういった実現手段が有効かが決められることによります。逆に、ステークホルダーを特定し、その価値観や要求を特定しない限りは、実現法は一意には決められません。いずれの場合も、要求と実現した成果物との追跡性の問題を引き起こします。
さて、こうした概念モデルの特徴を見ると、概念モデルをベースとしてモデル駆動型開発を行うことは非常に困難と言えるでしょう。私は、実績により技術の有効性を判断する立場に立つので、OMGのMDA（Model Driven Architecture）の芳しくない実績を考えると、この判断は正しいと思えます。モデル駆動型開発では、モデルを変換して最終的にソースコードないしバイナリーコード（中間言語を含む）に落とすか、モデル自体を仮想マシンで動作させるかの手段をとります。いずれの場合も、モデルは、実行可能になるために十分な記述能力を持っている必要があります。
ビジネス分野において概念モデルに要求される実現機能には、データ関連に限れば、クエリー、分析、報告、統合、同期などの代表的な操作があります。もしこれらの操作が、十分に汎用性が高く、かつプラットフォームに依存しない、ないし、特定の実装との関連づけを制約なく行うことができるのであれば、概念モデルに適切なアノテーションを追加することで、実行可能となりうると想像できます。
データに関しては従来、論理設計でのERDが主流でしたが、保守性や実装技術の選択肢の自由度を考えると、概念モデルを中心とした実装技術への移行が有利と考えられます。ただ、ここでは、概念モデルが実行可能であることが前提となります。
概念モデルによるアプリケーション設計の流れは、Microsoft社がVista（Longhorn）で実現しようとして一度は頓挫したWinFSの流れを組むものです。現在のOOPのクラスやオブジェクト、RDBのテーブルと関係をベースとした、O/Rマッピング、データバインディング、プロキシー生成などを根本的に変化させる技術です。この技術は、ADO.NET Entity FrameworkでOrcas以降に提供される予定です。
こうした流れはC#などOOPの言語仕様に関数型パラダイム（匿名関数、匿名メソッド、ラムダ式、クロージャ）などを導入したマルチパラダイム言語の登場とあいまって次世代の開発基盤を構成します。