Stack Overflow Blogに掲載された記事は、モデル指向プログラミング（Model Oriented Programming）という概念を見直すよう呼びかけている。これは、システム要件とソフトウェア設計を分離し、その後、モデル自体をシステムの作成と保守に役立てることができる方向性である。筆者は、13年前にMo+という言語と開発環境を開発した過去の経験を基にしており、これらを企業プロジェクトで使用したものの、この考え方は広く普及しなかったと述べている。
この記事は、利用可能な言語や新しい研究プロジェクトの発表ではなく、特に人工知能の重要性とソフトウェアシステムの複雑さが増している世界において、この分野でさらなる研究と開発を促す主張である。
構造とデータとしてのモデル
筆者は、モデルを2つの要素によって定義することを提案している。すなわち、規則またはスキーマを定める構造と、その構造に従うデータである。構造は階層的で、ルートノードから始まり、ノードとプロパティへ分岐する。必要に応じて、プロパティから別のノードを参照することもできる。この観点では、リレーショナルデータベースのスキーマを、データベース、テーブル、カラム、キーなどのノードを含む階層として表現できる。データ自体が行と関係に分散している場合でも同様である。
記事では、レストラン、顧客、従業員、メニュー項目、それらの関係を含む簡略化されたレストランのシナリオを使って、この考え方を説明している。同じシナリオを表現するために複数の構造を提示し、構造の選択がモデルの走査のしやすさや、モデルに依存するプログラムの記述方法に影響すると説明している。
モデル指向開発の4つの形態
- 非公式モデリング：頭の中や紙上にあるモデル、またはソフトウェアツールが直接利用しない図。
- 組み込みモデリング：コード内にモデルを置く方式。Entity FrameworkやNHibernateなどのORMフレームワーク、またはAngularやReactなどのユーザーインターフェースフレームワークが該当する。
- 結合モデリング：通常はUMLを使う外部モデルで、コード要素やその管理ツールと強く結び付いている。
- 分離モデリング：要件、データ、ワークフローに焦点を当てたモデルで、コードの詳細設計は別に任せる方式。モデルの各要素が特定のソフトウェアコンポーネントに直接対応することはない。
筆者は、最大の可能性があるのは結合モデリングと分離モデリング、特に後者だと考えている。後者は要件をモデルに、設計をコードに置くためであり、筆者の個人的な経験では、この分離によってモデリングとプログラミングのプロセスがより円滑になったという。
モデルからシステムへ
記事では、モデル指向プログラミングの利用を3つの領域に分けている。移行型では、プログラムがモデルを解釈し、後から開発できるソースコード、設定ファイル、またはドキュメントを生成する。モデルのモデリング型では、言語がモデルの構造とデータの作成および保守を支援する。目標型では、言語を直接使ってシステム環境を構築・管理するため、より完全な言語が必要になる。
提案される言語の機能
主な提案の1つは、モデルの構造を言語の文法の一部にすることである。これにより、Entity、Property、Relationshipなどのノードを、それらを表現するための専用のクラスやオブジェクトを作成することなく、直接扱えるようになる。また筆者は、データツリー内でのプログラムの位置に基づくモデルコンテキストも提案している。このコンテキストには、親ノードへ上がったり、子要素へ下りたり、それらの間を検索したりできるスタックが備わる。
もう1つの考え方として、「モデル指向プロパティ」がある。これは特定のノード型に結び付いた独立したコード部分であり、複数のインスタンスに対して評価できる。これらのプロパティを組み合わせて、クラス定義やそのプロパティの作成などのコードを生成したり、検索やフィルタリングの処理に利用したりできる。移行型では、プロパティにput操作を含め、結果をファイルまたは対象環境に保存することもできる。
筆者はさらに、プログラミングセッションの開始時に、インタープリターがモデルのノードとプロパティを言語の文法へ追加する動的規則を提案している。これは、標準モデルに十分な情報が含まれていない場合や、特定の組織または分野に固有のモデルを扱う場合に役立つ。また、プログラムの異なる部分で許可される操作を制限するコンテキスト規則も提示しており、副作用を減らし、読み取りと書き込みの責任を分離することを狙っている。
なぜこの提案が重要なのか
この考え方の実務的な価値は、モデルを開発サイクルから切り離された単なる設計文書ではなく、実行可能なものにしようとする点にある。要件、データ、ワークフローを、再利用可能な生成および保守の仕組みに結び付けられれば、モデルとコードの間の重複を減らせる可能性がある。しかし記事は、標準化された言語、利用可能なツール、またはこのアプローチが現在のモデリングおよびコード生成フレームワークより優れていることを示す比較結果を提示していない。
重要な疑問も残されている。大規模で変化するモデルをどのように管理するのか。生成されたコードをどのようにテストするのか。動的規則には、可読性、安全性、開発ツールとの統合の面でどのような限界があるのか。そのため、この記事は即時利用できる完成済みの解決策というより、言語開発者や研究者にとって価値のある研究への呼びかけと見るのが適切である。