CommonMP 要素モデル開発メモ

• .NET Framework における名前の付け方について
• 要素モデルの名前のユニークな付け方について（2010年11月15日)
• 要素モデル KyotoUnivHydrologyFileOutputBasic の使い方（2010年8月22日)
• Debug の仕方（2010年8月22日）
• SCFconverter （2010年8月6日）
• コマンドラインでの実行の仕方 （2010年8月6日）
• 要素モデルのコンパイルの仕方 （2010年5月16日）
• 要素モデルのファクトリーへの設定
• 開発メモ

[.NET Framework における名前の付け方について（2010年11月20日)]

名前空間やクラス、変数などの名前の付け方の原則について、以下のようなルールがある。従う必要はないが、ソースコードを読みやすくするために従うことにする。

識別子が複数の単語で構成される場合、アンダースコア ("_") やハイフン ("-") などの区切り記号を単語の間に使用しない。大文字小文字の区別を使用して各単語の先頭を示す。一般的に使われる形式は以下の2つである。

1. Pascal形式：識別子の最初の文字と、後に続いて連結されている各単語の最初の文字を大文字にする。

   例：BackColor

2. Camel形式：識別子の最初の文字は小文字にし、後に続いて連結されている各単語の最初の文字を大文字にする。

   例：backColor

識別子に適用される一般的な規則は以下の通り。

1. 複数の単語で構成されるパブリック メンバー、型、および名前空間の名前には、常に Pascal 形式を使用する。
2. パラメーター名には Camel 形式を使用する。

名前の付け方の具体例は以下の通り。

1. アセンブリとDLLの名前の付け方の例
   • アセンブリと DLL がライブラリの物理的な編成であるのに対し、名前空間は論理的な編成であり、アセンブリの編成とは独立した要素として考える必要があります。
   • 名前空間が複数のアセンブリにまたがることも少なくありません。アセンブリ DLL の名前には、System.Data のような、主要な機能を示す名前を選択します。アセンブリ名や DLL 名が名前空間の名前に対応している必要はありませんが、アセンブリの名前を付ける場合は、名前空間の名前に従うのが妥当です。
   • 次のパターンに従って　DLL　に名前を付けます。
   • <Company>.<Component>.dll
   • <Component> には、コンポーネントを指定します。複数のコンポーネントを指定する場合は、ドットで区切ります。
   • たとえば、Contoso.WebControls.dll のように指定します。
2. 名前空間の名前
   • 名前空間の名前の一般的な形式は次のとおりです。
   • <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
   • たとえば、Microsoft.WindowsMobile.DirectX などです。
3. クラス、構造体、インターフェイスの名前
   • 一般に、型名は名詞句にする必要があります。
   • Pascal 形式を使用して、名詞、名詞句、または場合によっては形容詞句で、クラス、インターフェイス、および値型に名前を付けます。
   • クラス名には、プリフィックス (C など) を使用しないでください。
   • I で始まる必要のあるインターフェイスは、この規則の例外です。
   • 派生クラスの名前は、末尾に基本クラスの名前を付けるよう考慮します。たとえば、Stream から継承した .NET Framework の型は名前の末尾を Stream にします。
   • インターフェイス名には、その型がインターフェイスであることを示すために、プリフィックス I を付けます。
4. メソッドの名前
   • メソッド名には、動詞または動詞句を割り当ててください。
5. プロパティの名前
   • プロパティの名前には、名詞、名詞句、または形容詞を使用してください。プロパティはデータを保持するため、名詞句や形容詞が適切です。
6. イベントの名前
   • イベントの名前には、動詞または動詞句を使用してください。イベント名には、現在形と過去形を使用して、前後の概念を与えてください。たとえば、ウィンドウを閉じる前に発生させるクローズ イベントには Closing という名前を付け、ウィンドウを閉じた後に発生させるクローズ イベントには Closed という名前を付けます。
7. フィールドの名前
   • フィールド名には Pascal 形式を使用してください。フィールドの名前には、名詞や名詞句を使用してください。
8. パラメータの名前
   • パラメータ名には Camel 形式を使用します。パラメータ名には説明的な名前を使用します。

[要素モデルの名前のユニークな付け方について（2010年11月15日)]

要素モデルを実現するクラスを識別するために名前を付ける。そのために、ソースコード ModelDefine.cs で以下の名称を指定する。

1. ファクトリ名称：public static readonly HySID HYDROLOGY_MODEL_LIB = new HySID("KyotoUnivEngHywr.KinematicWaveModel.Fctry");
2. モデル種別名称：public static readonly HySObjectKind HYDROLOGY_LINEAR_RESERVOIR_KIND = new HySObjectKind("KyotoUnivEngHywr.KinematicWaveModel");
3. モデル名称：public static readonly HySString HYDROLOGY_LINEAR_RESERVOIR_NAME = new HySString("KyotoUnivEngHywr.KinematicWaveModel");

ファクトリ名称とモデル名称は要素モデルごとに固有のものでなくてはならない。実際、構造定義ファイル(XML ファイル)では、ファクトリ名称とモデル名称によって要素モデルを区別する。名前空間名+クラス名が要素モデルでユニークであることに対応して、上記の文字列もユニークなものでなくてはならない。したがって、次のような名前の付け方が基本となる。

• 名前空間名: 組織名称とする。たとえば KyotoUnivEngHywr など
• クラス名: 要素モデルの機能に合わせた名前。たとえば KinematicWaveModel など
• ファクトリ名: 名前空間名+クラス名+ファクトリ名。たとえば kyotoUnivEngHywr.KinematicWaveModel.Fctry など
• モデル名: 名前空間名+クラス名。たとえば KyotoUnivEngHywr.KinematicWaveModel など

上の例ではモデル名称を namespace.クラス名、ファクトリ名称を モデル名称.Fctry としている。

[要素モデル KyotoUnivHydrologyFileOutputBasic の使い方（2010年8月22日)]

加藤君が作成してくれた KyotoUnivHydrologyFileOutputBasic の便利な使い方。

1. 結果のファイル出力に利用する基本的な要素モデルである。
2. プロパティ設定画面で出力ファイル名を指定する。このとき、ファイル名に * を入れると、そこに整数が入ってすべての出力情報がファイル出力される。数字は 、DataFusion で指定する csSndCellData[0].m_dData[0] = mInf.m_outflow; csSndCellData[0].m_dData[1] = mInf.m_runoffHeight の配列の添え字に対応する。
3. 注意。要素モデルが複数の出力情報を持つ場合、プロパティ画面の「ファイルを出力するセル番号」で 0 以外の番号を指定すると，プログラムが正常に動作しない。

[Debug の仕方（2010年8月22日）]

新規にモデルを開発する場合のデバッグ環境が用意されている。使い方は以下の通りである。

1. ソースコードのひな型を用意する。たとえば C:\home\tachikawa\2010\prog\commonmp\source\KyotoUnivHywrStorageFunctionModel-v10 以下に ソースコードをおく Model/ とプロジェクトファイルをおく。
2. C:\Program Files\CommonMP\Source\HYMCO\OptionImpl\ModelDeveloperExpressEdition にデバッグ環境が準備されている。ここにある TestModelDeveloperMainExp.sln をクリックして Visual Studio を立ち上げる。
3. ソリューションエクスプローラの一番上の「ソリューション」を右クリックして「追加=>既存のプロジェクト」として、1.で準備したひな型のプロジェクトファイル (ex. KyotoUnivHywrStorageFunctionModel.csproj を指定する。これによってプロジェクトが TestModelDeveloperMainExp.sln に追加される。
4. 次に、TestModelDeveloperMainExp.sln のソリューションエクスプローラのTestModelDeveloperMainExp の下の「参照設定=>参照の追加」の「プロジェクトタブ」で 3. で指定したプロジェクトを指定する。これによって KyotoUnivHywrStorageFunctionModel が参照に加わる。これでDebug 環境の準備はおしまい。
5. プログラムを作成し、ビルドする。次に、「デバッグ=>デバッグの開始」とすると CommonMP が立ち上がり、デバッグを開始することができる。
6. 注意。ここで作成された DLL ファイルはソースコードのあるフォルダーの下の bin/ とC:\Program Files\CommonMP\Source\HYMCO\OptionImpl\ModelDeveloperExpressEdition\bin\Debug の下に自動的にコピーされる。デバッグ用の CommonMP もここにある。もし、他の要素モデルを使ってデバッグする場合は、ここに使いたい DLL を置く必要がある。また、最終的には C:\Program Files\CommonMP\Execute\bin に完成した DLL をおく必要がある。

[SCFconverter（2010年8月6日）]

加藤君が作成しれくれたOhymos用の構造定義ファイルをCommonMP用の構造定義ファイルに変換するプログラム。任意の要素モデルに対応することは困難なため、OHyMoS でよく利用する要素モデルのみ対応している。OHyMoS の要素モデル名と CommonMP の要素モデル名はプログラムの中に埋め込んでいる。CommonMP 側の要素モデルの名前やファクトリークラスの名前を変える場合は、それに対応して SCFconverter もソースプログラムを変更する必要がある。

[コマンドラインでの実行の仕方（2010年8月6日）]

要素モデルの個数が非常に大きい場合、構造定義ファイルを読み込まないことがある。九頭流川の分布モデルの場合、要素モデル数が519個、入力ファイル数が4個、出力ファイル数が1299個であり、合計して1822個の要素モデルを実行することになる。この場合、画面では読み込まなかったが、コマンドライン上では正常に計算することができた。コマンドラインで計算する方法は以下の通りである。

1. C:\Program Files\CommonMP\Execute\conf の下にある HymcoCUI.cfg を編集し、プロジェクトファイルを置くディレクトリを指定する。

# CUI 作業ワークディレクトリ（フルパス設定）
CUI_WORK_DIRECTORY = C:\home\tachikawa\2010\prog\commonmp\kuzuryuGawa\

1. C:\Program Files\CommonMP\Execute\bin に移動する。ここで実行しないとうまくいかないようだ。
2. 以下のコマンドで実行する。hymco.exe -c projectFile.xml
3. 上のコマンドで -c 以下にプロジェクトファイル名を指定する。このプロジェクトファイルは以下の例ように構造定義ファイルと計算時間を指定する。
4. 構造定義ファイルでデータを読み込む場合、C:\Program Files\CommonMP\Execute\bin からの相対パスで指定するか、絶対パスで指定する。

プロジェクトファイルの例

<?xml version="1.0" encoding="utf-8" ?>
<HymcoProject Name="ProjectSample">
<SCFile FileName="SCF_typhoon23_2004Nodam2.xml" />
<Simulation>
<Time start="2004/10/1 15:00:00" goal="2004/10/3 15:00:00" delta="72" Unit="sec" />
</Simulation>
</HymcoProject>

[要素モデルのコンパイルの仕方（2010年5月16日）]

自分のディレクトリに要素モデルのプログラムを置いてコンパイルする方法

たとえば C:\home\tachikawa\Source の下に、要素モデルごとにプロジェクトに対応するフォルダ、たとえば.\KyotoUnivKinematicWaveModel を置く。このとき、CommonMP によって用意されている DLL は C:\Program Files\CommonMP\Execute\bin にあるので、これを参照できるように設定する。その手順は以下の通り。

1. KyotoUnivKinematicWaveModel.sln をクリックして Visual Studio を立ち上げる。
2. ソリューションエクスプローラの KyotoUnivKinematicWaveModel を右クリック して「プロパティ」を選択する。
3. 「アプリケーション」でアセンブリ名（DLL名） KyotoUnivKinematicWaveModel(.dll) を指定する。
4. 「既定の名前空間」で name space 名を指定する。ここでは KyotoUniv.KinematicWave.Model とする。
5. 「参照パス」でフォルダ名として C:\Program Files\CommonMP\Execute\bin を入力し、「フォルダの追加」をクリックする。これで参照されるようになる。
6. ./bin/Debug/KyotoUnivKinematicWaveModel.dll を C:\Program Files\CommonMP\Execute\bin の下にコピーする。

[要素モデルのファクトリーへの設定 ModelFactory.cs]

public override HySDataLinkedList GetCalModelInfoList()
{
McModelInfo csModelInfo=null;

csModelInfo = new McModelInfo(
(HySID)this.GetFactoryID(),
McModelLibraryDefine.DIVISION_CALCULATION_MODEL,
new HySObjectKind("CAL_RIVER_MODELS"),
//
// C:\Program Files\CommonMP\Execute\conf\LibraryCategory.xml にある項目から選択する。
//
KyotoUnivHydrologyModelDefine.HYDROLOGY_LINEAR_RESERVOIR_KIND,
KyotoUnivHydrologyModelDefine.HYDROLOGY_LINEAR_RESERVOIR_NAME);
csModelInfo.SetVersionInf("Ver1.1 May 21, 2010");
csModelInfo.SetSummaryInf("線形貯水池モデル");
csModelInfo.SetCreatorInf("京都大学大学院 水文・水資源学研究室");
csModelInfo.SetIconName("Lane");
//
//C:\Program Files\CommonMP\Execute\ModelIcon の下にあるアイコン名から選択する。
//
m_csCalModelInforList.AddLast(csModelInfo);

return m_csCalModelInforList;
}

開発メモ

2010年5月22日
C:\Program Files\CommonMP\Execute\bin に dll を置いても、CommonMP に認識されないことがあった。いろいろ調べた結果、C:\Program Files\CommonMP\Execute\conf に HYMCO.dicon が見えない形で存在していることに気がついた。HYMCO.dicon が C:\Program Files\CommonMP\Execute\conf があると、そこに記述されている dll しか、登録されない。

2010年5月16日
KyotoUnivHydrologyModel.dll の中にある kinematic wave モデルを取りだし、kinematic wave モデルのみのプロジェクトファイル KyotoUnivkinematicWaveModel とそれに対応する KyotoUnivKinematicWaveModel.dll を作成した。

2010年5月16日
CommonMP ホームページにあるプログラム開発環境 EnvironmentalSetup.lzh をインストールした。インストールすると、 C:\Program Files\CommonMP\Source\HYMCO\OptionImpl の下に .\ModelDeveloperStandardEdition ができる。どうやって使うのか、よくわからない。 .\ModelDeveloperExpressEdition は Visual C# エクスプレスエディション用の開発環境とマニュアルにはあるが、 MicroSoft Visual Studio 2008 でも使える。

2010年5月15日
加藤が作ってくれた KyotoUnivHydrologyModel.dll の中にある 線形貯水池モデルにバグがあり、それを修正した。 また、ひとつの要素モデルに対して一つの dll の方が保守が容易 なので、線形貯水池モデルのみのプロジェクトファイル KyotoUnivLinearReservoirModel とそれに対応する KyotoUnivLinearReservoirModel.dll を作成した。