155. モデル、モデル図 ～ 一考 その２

前回の記事　　　　　　　　　　　　　　　　　　　　　　　　次回の記事

はじめに

前回は、“モデル”とは、“モデリング”とは何ぞや、についての私の見解を述べてみました。今回は、モデル図について見解を述べることにします。

モデル図 ＝ モデル × 表現形式

前回、

と説きました。モデル図の作成は、考覚を通じて浮かんだモデル、思考を通じて作られたモデルを言語化して、何らかの形式に従って、図示化する、というステップを踏みます。

何故そんなことをするかと言えば、自分自身も含めた他者と思考を共有（一瞬前の自分と一瞬後の自分は同じような思考を継続できるかもしれないが、数か月後の自分が同じ思考を継続しているとは限らない）するためです。

なぜ図示化するかと言えば、“図や絵の方が直観的にに判りやすい”と一般的に言われているからです。モデルを他者と共有する場合、図で表現しなければならないという、原理的な必然性はありません。
“図や絵の方が直観的にに判りやすい”を逆から読めば、“直観的に判りにくいような、巨大なモデルや複雑な混乱したモデルは図示に向いていない”となります。その時は、YAML や JSON、XML のようなフォーマットに従ってテキストで記述するという選択もよいでしょう。

左は図形式、右はテキスト形式で、見た目は異なりますが、どちらも“商品販売”という概念ドメインの”オーダー”という概念クラスを表現したもので、モデルの内容は同一です。
何が違うかと言えば、

• 左の図形式

  • 概念クラスを四角形とする

  • 四角の上の方に概念クラスの名前のテキストを配置する

  • その下に、名前とデータ型を“:”で区切って特徴値をリスト表記したテキストを配置する

• 右のテキスト形式

  • YAML の文法にしたがう

  • Conceptual_classes の子要素として概念クラスの名前を記述する

  • 概念クラスの名前の子要素として特徴値を名前とデータ型を“:”で区切ってリストで記述する

という異なるルールに基づいているということ。それぞれに出てくる”概念クラス”や”特徴値”は、モデルとして記述された特定の概念クラスや特徴値を指すものではなく、それが故に、どんな概念ドメインの概念クラスでも、図やテキストとして表現できるようになっています。
この図形式、テキスト形式は、表現・記述したいモデルそのものとは、また別の独立したそれぞれの意味の場です。表記の形式という意味の場もまた、概念モデルとして厳密に記述することも、もちろん可能です。ある意味の場のモデル、ある意味の場のモデル図、図表記のモデル、概念モデルのメタモデルは、下図のような関係にあります。

図にしろ、テキストにしろ、他者（コンピュータも含む）との共有が目的なので、その形式（意味の場、より厳密に言えば、そのスキーマを記述した概念モデル）は、その他者と共有されていること、が必要条件となります。

ソフトウェア関連のモデル記法の標準と言えば、UML（Unified Modeling Language）でしょう。実際、UML の標準書を読めば、メタモデルという名前で、UML のクラス図で記述され、定義されているのを見つけることができます。概念モデリング的な観点からすると、“Unified”＝“どんな意味の場のモデルでも対応可能”といえます。最も、概念モデリングで使うモデルの道具立てはとてもシンプルなので、UML のような複雑なモデリング言語に従わなくても、十分意図は伝わるので、特にUMLに厳密に従わなくても、概念情報モデル、状態モデル、アクション記述がぱっと見で分かるレベルの図なら何でも構いません。

テキスト形式の場合は、EBNF（拡張バッカス・ナウア形式） 等を使った定義が一般的でしょう。C# は EBNF での定義と、それに従ったメタモデルに相当する、クラスライブラリが提供されています。

図表記にしろ、テキスト表記にしろ、重要なことは、何をモデル化しているかを常に意識することです。モデルの図表記にしろ、テキスト表記にしろ、“モデルの中身が対応している意味の場”と“表記法の意味の場”との掛け合わせでできています。もちろん正しい図やテキストを記述するためには、表記法の正しい理解は必須ですが、自分が表現しようとしているのは何か、それに対する適切な表記は何か、という順番で考えると、比較的早く表記法を習得できるでしょう。

様々なモデル表記

Microsoft Fabric ‐ Digital Twin Builder

Microsoft Learn のチュートリアルから幾つか図を抜粋することにします。