６章 再び要素モデルの作成
前章までで、要素モデル開発の基本と、要素モデル動作を理解する上で必要なCommonMPの計算制御について、簡単に勉強して来ました。
この章では、開発する範囲を広げてみたいと思います。
具体的には、要素モデルのプロパティ設定画面を、独自の画面に変更します。 またプロパティ情報クラス、初期化情報クラスも独自のクラスを制作してみます。
要素モデルは計算論理を受け持ち、CommonMPが提供する要素モデル親クラスからの派生を作成すれば、CommonMPのフレームワーク上で、プロパティ画面が表示できました。 要素モデルは、プロパティ画面の存在を知らないでも良かったわけです。
独自のプロパティ画面を作成する場合でも、この思想は継承されます。 すなわち、要素モデルとは無関係に（要素モデル側のDLLに一切手を加えること無く）独自画面表示の仕組みを作成することになります。
これは、CommonMPの設計に 「MVC」（Model-View-Controller）ソフトウエアパターンという概念が導入されているためです。 この思想に従うと、モデルは画面に関わる処理を一切してはならず、View部が画面処理を一手に引き受けることになります。 CommonMPでの、Controllerに相当する部分は、第４章で示した要素モデルの計算制御を行う部分ではなく（要素モデルの計算制御はModelに含まれる）、画面の計算開始／終了等のボタンの操作を受けて、シミュレーション全体を制御したり（特に複数のプロジェクトが同時に計算を行えるように制御）、プロジェクトの入出力を制御したりする部分になります。
この様に明確に機能分担を行うことで、将来の拡張に、各部の仕様変更を、他の部分に影響を及ぼすこと無く行えるようになります。
例えば、CommonMP
Ver1.2
では、CommonMPの計算機能を利用して、簡易型の予測システムが構築できる機能が追加されました。 この時にはCommonMPは標準の制御画面とは異なる別の制御画面から シミュレーション計算の開始／終了を指示します。 しかしながら、画面が変更されても、CommonMPのプロジェクト内のモデルには一切変更は発生しません。 将来CommonMPの計算機能だけを他のシステムに組み込む事があるかもしれませんが、その時でも内部に構築されたプロジェクトは一切手を加えること無く（標準のCommonMPで制作したプロジェクトがそのまま）利用可能です。 また、仮に Web上からサーバーのCommonMPを動作させたいという要求が発生したとしても、要素モデルや計算プロジェクトがそれに影響を受けて修正しなければならないという事態を回避できます。
上記のように MVCソフトウエアパターン構造を採用しているので、要素モデル開発者が独自画面を作成する場合には、別なDLL（プロパテイ画面用のDLL）を制作し、それを提供する必要があります。
初版：2013/07/12 |