115. ものごとを形式で把握する

前回の記事　　　　　　　　　　　　　　　　　　　　　　　　次回の記事

はじめに

この記事が公開されるのは12/30、本当に一年って早いですね。厄年の影響もろ受けの一年でした。寺社仏閣のご利益を受けやすい人は、厄年の影響が強い気が…
さて、文字化けの原因も分かって、Azure Ditigal Twins の Twin Model 定義を DTDL で、概念情報モデルから生成できたのが今ここ、でした。
今年も最後ということで、この生成過程において、何が重要なのかを振り返ることにします。

複数の概念ドメインの対応付け

まず、なぜ、概念情報モデルから Twin Model が生成できるのでしょう。

概念モデリングによる、概念モデルとTwin Model の概念モデル化

概念情報モデルは、モデル化対象を目的とする意味の場を通じて拾い上げた事柄、事柄の性質、事柄間の意味的つながりの構造を規定するスキーマモデルでした。概念モデリングは、哲学的認識論、存在論を元にした人間の認識と表現の形を元に、演繹的、かつ、綜合的に組み立てた体系であり、モデル作成者の意味の場を通じた理解を記述することにおける基本的な枠組みを提供します。この枠組みは、”概念モデリングとは？”という意味の場を設定して、概念モデリング自身の概念モデルを記述することが可能です。同様に、同じ仕組みで、Azure Digital Twins の概念モデルも記述が可能です。
そのモデリングを実際に行うことにより、以下の二つの概念ドメインの概念モデルが出来上がります。

• 概念モデリング

• Azure Ditigal Twins

出来上がったモデルはそれぞれの意味の場を厳密に記述した概念ドメインを構成します。言い換えると、”概念モデリングとは？”、”Azure Digital Twins とは？”の意味の論理空間が厳密に定義されることになります。

それぞれの概念ドメインは、お互いに独立していて、無関係です。

二つの概念ドメインを対応付ける概念ドメイン（意味の場）を設定する

二つの概念ドメインが無関係なままでは、その先には進めないので、二つの概念ドメインとして記述されたモデルの構成要素の対応付けを行う概念ドメイン（意味の場）を設定し、モデル化します。
概念モデル⇒Twin Model の場合は、左側を概念モデル、右側をTwin Model とすると、

• 概念クラス ⇒ Twin Model の Twin

• 概念クラスの特徴値 ⇒ Twin Model の Twin の Property

• Relationship ⇒ Twin Model の Relationship

• 概念インスタンス ⇒ Twin Graph の Twin

• 概念インスタンスの特徴値 ⇒ Twin Graph 上の Twin の値を持った Property

• リンク ⇒ Twin Graph 上の Twin 間のリンク 

という対応付けを行う、概念モデルで記述した概念ドメインを定義したことになります。
ちなみに、これまで書いてきた、歩行解析の健診受診に関する記事で紹介した、この意味の場に対する概念モデルでは、”医師”や”対象者”等の概念クラスが定義された概念情報モデルを紹介してきましたが、これらの概念クラス群は、上のリストで書いた”概念クラス”の概念インスタンスです。
圏I と圏C（圏Iのスキーマ） を区別しながらこの記事を読んでください

この様な二つの概念ドメインの間の対応付けのことを、概念モデリングのベースになっている Shlaer-Mellor 法では、ブリッジ（Bridge）と呼んでいます。

対応付けを行えば、その対応付けのルールに従って、”健診受診”の概念情報モデルの要素が Azure Digital Twins の Twin Model のどれにあたるかを決めていくことができるわけです。その対応ルールを文書化すると、誰かほかの人に、「このルールに従って、概念情報モデルの内容を、DTDL 化してね…」なんというお願いができることになります。

モデルを形式に従って描く

さて、概念モデリングは、意味の場を通じて、事柄、事柄の性質、事柄間の意味的つながりを拾い上げていくという、哲学的な基盤から演繹的・綜合的に体系づけているだけでなく、厳密な検証が行えるよう、数学的・論理学的な観点からの記法も持っています。
この様な体系は、その記法を元にした、厳密なルールを記述することを可能にします。
もしも、モデルの記法が曖昧であれば、それを元にしたルールも曖昧になってしまい、そのルールを個々人が解釈する時、実行する時の恣意性が生まれることを防ぐことができません。
一方で、概念モデリングでは、”概念モデリング”の”概念モデル”を使って、厳密なルールを記述することが可能です。

厳密な形式に従ったモデルは、記述内容を機械的に取り出せる

健診受診のモデルも、概念モデリングの記法に従って記述がなされているので、その厳密なルールに従って、記述内容を、全て正確に取り出すことができます。
取り出した内容・項目を、Azure Ditigal Twins の Twin Model のどれに割り当てるか、これを、例えば、Visual Studio の T4 Template で記述してやれば、元ソースの取り出し方、取り出した項目の変換方法をコンピュータ上で実行できるぐらいの厳密さで記述することができるわけです。

これが、DTDL の生成の仕組みです。

全ての意味の場に適用可能

ここまで、健診受診を例には出しましたが、形式を規定しているのは概念モデリングそのものなので、健診受診という特定の意味の場だけでなく、全てのモデル化対象になりうる意味の場に、ここまでの議論は適用可能です。
前にも書いた通り、概念モデリングは、人間の言語を前提とした思考のフレームと同じフレームを基礎においているので、人間の認識対象全てに対応可能であることになります。

形式的に記述された概念モデルの応用

106回の記事で、Domain Function を紹介しました。
昔々の長閑な CRUD で十分なシステムの場合であれば、それに必要な Domain Function は、比較的簡単なルールを作成すれば、概念情報モデルから網羅的に導出可能です。
もしかすると、概念モデルをソフトウェア実装と同じ意味の場だと勘違いしている読者もいるかもしれないので、念のため書いておくと、概念モデルで記述されているものは、構築するソフトウェアが実装するべき仕様です。
今回説明してきたやり方は、概念モデルから、非機能要件を満たせるものとして選択された実行プラットフォーム上で動作可能なソフトウェア一式を自動生成できるのですが、もし、誰かがモデルを描いて、それを見ながらコードを手書きしていくような非効率な方法を、何らかのやんごとなき事情でとるような場合もあるかと思います。
そんな時は、テストケースぐらいは、概念モデルから自動導出するぐらいやっても良いかな、などと思っています。
概念モデル＝仕様なので、仕様書の自動生成も可能なので活用すると良いでしょう。

そういえば、昔々、ユースケース駆動型アプローチというものが出てきて結構はやりましたね。今もユースケースを書いている人はたくさんいると思いますが、概念モデリング有段者から見ると、意味の場混乱、随分と曖昧だなというのが実感。ユースケースも、ルールさえ決めれば、概念情報モデル、状態モデルから導出できるので、そうやれば、より正確で意味のあるユースケースが出来上がるような気もしています。

最後に

今年はこれでおしまいです。
皆様、良いお年を❣