見出し画像

112. 概念モデルから Azure Digital Twins 向けの Twin Model を生成する

前回の記事                        次回の記事

はじめに

前回の予告通り、これまで作成してきた健診受診の概念モデルから、Azure Digital Twins 向けの Twin Model の DTDL の文法に従った JSON ファイルを生成します。

変換ツール

DTDL による Twin Model は、Github で公開している

GitHub - kae-made/dtdl-iot-app-generator: This application generates IoT application framework which can collaborate with Azure IoT Hub from IoT PnP DTDL file

を使います。このリポジトリで公開しているのは、Visual Studio で作成したソリューション一式で

ソリューションの構成

のような構成をとっています。真ん中のプロジェクトは変換ツール本体を実装したライブラリ形式で、NuGet パッケージとして他のプロジェクトに組み込めるようになっています。
上と下のプロジェクトはそれぞれ、コンソールで、WPF による GUI で実行可能なアプリ形式のプロジェクトです。真ん中のライブラリを使用するサンプルアプリケーションという意味合いも持っています。

今回は、下の WPF による GUI アプリケーションを使うことにしました。

で、早速実行してみると…
あれれ?組み込んで使っている Kae.Utilities.Logging.WPF の実装に問題ありとのメッセージが出て実行できない!

調べてみると、今連載しているシリーズの最初のほうで行った、Kae.Utilities.Logging.WPF の NuGet パッケージのバージョン番号付けに問題があり、この WPF アプリプロジェクトで最新版が組み込まれていないことが判明しました。具体的には、過去既に”1.0.0”というバージョンを公開していたにもかかわらず、”0.10.0”で更新してしまっていた!
なので、Kae.Utilities.Logging.WPF について改めて”1.0.1”というバージョンを作って、NuGet に Publish し、それを WPFアプリ側で使用するようにして、問題解決!

Github も更新して作業完了

BridgePoint 側の変換に向けた準備

次に、BridgePoint で作成した概念モデルから、変換を行うのに必要なファイルを生成します。

作成したモデルの内容を記述したファイルの生成

変換に必要なファイルの生成

プロジェクトエクスプローラで、概念モデルのプロジェクトを右クリックして、”Build Project”を選択します。
すると、

生成されたファイル群

モデル作成のプロジェクト用に用意されたフォルダー直下に ”gen/code_generation” というフォルダーが作成されて、そこに、”プロジェクト名.sql”というファイルが出来上がります。このファイルの中身は、これまで作成してきた概念モデルの内容が概念モデリングのメタモデルのインスタンスとして格納されています。=作成したモデルのすべての内容が格納されているということです。

生成されたファイルのスキーマファイル

前のセクションで生成されたファイルのスキーマファイルは、概念モデリング(Shlaer-Mellor 法)という意味の場(概念ドメイン)をモデル化した概念モデルなので、どんな意味の場(概念ドメイン)の概念モデルを作成したとしても、すべて共通で同じものになります。この概念モデリングのスキーマは、BridgePoint の場合、

共通のファイル

と、BridgePoint をインストールしているディレクトリの下の tools/mc/schema/sql の下にある、xtumlmc_schema.sql です。string や integer など基本型は、tools/mc/schema の下の Globals.xtuml で記述されています。ちなみに xtumlmc_schema.sql は、SQL の文法を基本とし、概念クラス=TABLE に加えて Relationship が独立して定義できるようになっています。うんうん、オントロジー系の概念モデルならそうあるべき。

TwinModel(DTDL)を生成する

準備が整ったので Twin Model を生成することにします。

WPF アプリによる自動生成

Visual Studio で、WPF アプリをデバッグ起動し、以下のような設定を行って、”Generate DTDLs”をクリックします。

設定と実行

…おや?全部の概念クラスが生成されない!
調べてみると、

あらら Exception 発生

私以外の皆さんは、なんのこっちゃ?って感じだと思いますが、これは、私が概念情報モデルを作った過程で、列挙型のユーザー定義データを定義した際、その列挙子をまったく定義していなかったことに起因した Exception でした。

モデルの間違いの修正

確認してみると、HealthLevel という列挙型に列挙子がありませんでした。
以下のように修正。

列挙子の追加

再度、BridgePoint で、プロジェクトエクスプローラで、プロジェクトアイコンを右クリックし、”Build Project”を選択します。

再度、”Generate DTDLs”をクリックすると、

生成結果

今度は、一番最後の JSON ファイルの名前が文字化けはしてはいるものの、一通りの生成ができたようです。
生成先に指定したフォルダーをのぞいてみると、

生成先として指定したフォルダー

確かに生成されています。

試しに、HC_D.json の中身を見てみます。”医師”っすね。

{
  "@context": "dtmi:dtdl:context;2",
  "@id": "dtmi:jp:kae-made:HealthcareCasestudy:HC_D;1",
  "@type": "Interface",
  "comment": "auto generated - generator version=1.0.0",
  "displayName": "å»å¸«",
  "contents": [
    {
      "@type": "Property",
      "name": "DID",
      "writable": true,
      "schema": "string",
      "comment": "@I0,PR8_ë診æ­ãåãã_HC_D"
    },
    {
      "@type": "Property",
      "name": "æ°å",
      "writable": true,
      "schema": "string",
      "comment": "@I1"
    },
    {
      "@type": "Property",
      "name": "é£çµ¡ç¨ã¡ã¼ã«ã¢ãã¬ã¹",
      "writable": true,
      "schema": "string",
      "comment": "@I1"
    }
  ]
}

うむむ、文字化けしてる。。。
もう一つ、HC_MPLC.JSON を見てみます。”健診会場”ね。

{
  "@context": "dtmi:dtdl:context;2",
  "@id": "dtmi:jp:kae-made:HealthcareCasestudy:HC_MPLC;1",
  "@type": "Interface",
  "comment": "auto generated - generator version=1.0.0",
  "displayName": "å¥è¨ºä¼å ´",
  "contents": [
    {
      "@type": "Property",
      "name": "MPLCID",
      "writable": true,
      "schema": "string",
      "comment": "@I0,PR4_ëè£åããã¦ãã_HC_MPLC,PR6_ç測ã£ã_HC_MPLC,PR12_îè¨æ¸¬å¨ç®¡çãæã_HC_MPLC,PR13_îå¥è¨ºæ _HC_MPLC"
    },
    {
      "@type": "Property",
      "name": "ä¼å ´å",
      "writable": true,
      "schema": "string",
      "comment": "@I1"
    },
    {
      "@type": "Property",
      "name": "æå¨å°",
      "writable": true,
      "schema": "string"
    },
    {
      "@type": "Property",
      "name": "責任èæ°å",
      "writable": true,
      "schema": "string"
    },
    {
      "@type": "Property",
      "name": "LGDID",
      "writable": true,
      "schema": "string",
      "comment": "@I0,PR4_ëè£åããã¦ãã_HC_MPLC,PR6_ç測ã£ã_HC_MPLC,PR12_îè¨æ¸¬å¨ç®¡çãæã_HC_MPLC,PR13_îå¥è¨ºæ _HC_MPLC,I1,R3"
    },
    {
      "@type": "Relationship",
      "@id": "dtmi:jp:kae-made:HealthcareCasestudy:R3_Éå¶ããã¦ãã_HC_LGD;1",
      "name": "R3_Éå¶ããã¦ãã_HC_LGD",
      "maxMultiplicity": 1,
      "target": "dtmi:jp:kae-made:HealthcareCasestudy:HC_LGD;1"
    }
  ]
}

こちらも文字化けしてますが、特徴値に加えて、Relationship も生成されています。

文字化けは、モデルを全部英語で書けば、問題ないのですが、それじゃだめだよね。。。

最後に

今回はここでいったん終わりです。次回は、このジェネレータのもう少し詳しい仕組みを語るとともに、この文字化けの問題解決を目指すことにします。

ここから先は

0字

2022年3月にマイクロソフトの中の人から外の人になった Embedded D. George が、現時点で持っている知識に加えて、頻繁に…

この記事が気に入ったらチップで応援してみませんか?