見出し画像

2. 概念情報モデルを使う

本ドキュメントの利用は、https://github.com/kae-made/kae-made/blob/main/contents-license.md に記載のライセンスに従ってご利用ください。

https://github.com/kae-made/kae-made/blob/main/contents-license.md

Date: 2023/11/26 - Version: 1.2.1


はじめに

「概念情報モデリング」の章では、概念情報モデルを構成する要素と表記法の説明と、概念モデリングの進め方について解説しました。本章では、概念情報モデルの使い方について解説していきます。

概念情報モデルと現実世界を表現する概念インスタンス群

注目しているビジネス要件に関わる様々なデータに関する今の状態は、概念情報モデルで定義されたルールに従って存在する、概念インスタンス、概念インスタンスの関係、概念インスタンスの特徴値の値で保持されます。例として、“商品販売”ドメインが下図で例示した概念情報モデルで定義されている場合、

画像1
図1. ”商品販売”ドメインのシンプルな概念情報モデル例

現実のビジネスの世界を表現する概念インスタンスは、例えば、下図のような概念インスタンスと概念インスタンス間の関係で表現されます。

画像2
図2. 図1の概念情報モデルに従った現実世界の概念インスタンス群の例

読者の理解を深めるため、“装置管理”ドメインについても例示しておきます。

画像3
図3. ”装置管理”ドメインの概念情報モデルの例

概念インスタンス群とその関係を図示する場合は、上の図のように、アイコンの利用や配置関係など、モデル化対象のドメインに即した工夫をすると直感的に分かりやすく表現できます。この概念インスタンスの絵では、概念情報モデルで定義された関係を網羅して描いているので、どの関係が図のどの部分に対応するかを考えてみてください。

重要なので、何度も繰り返しますが、ビジネスが“今どうなっているか”を、概念インスタンスとその間の関係で表し、存在しうる概念インスタンスと関係の制約を概念情報モデルで定義します。

概念インスタンスをコンピュータ上で保存する

次に、上の3つの図で例示した概念インスタンスを電子化してコンピュータ上で保存する方法を考えてみます。
概念クラスは、概念インスタンスが持つべき特徴値を定義しているので、概念クラス毎に特徴値をカラムにした表を用意すれば、存在する概念インスタンスを全て表形式で表せます。

画像4
図4. 概念インスタンス群を表形式で表現する

表で概念インスタンスを表現した場合、他の概念インスタンスとの関係を明示するために、“参照を表す特徴値”の必要性です。また、その特徴値で値を使うために、モデル化対象のドメインにおいて意味を持つような識別子的な特徴値がない場合でも便宜的な識別子が必要であることがご理解いただけるでしょう。
表形式で上から順に概念インスタンスが並べられて表示されていますが、その並びには、一切、意味はないことには注意が必要です。モデル化対象のドメインにおいて、意味のある並びがあるなら、その順序を概念クラスや関係を使って定義しなければなりません。

様々な表現形式

概念インスタンスの状態を表形式にしてしまえば、電子化してコンピュータ上に保存するのは簡単です。保存方式の例として、CSVやJSONによる表現を紹介しておきます。

CSV形式

顧客ID,顧客名,住所
C003,概 念,XXX
C172,円 帝一,YYY
C026,蔵巣 抽,ZZZ
...

を、"顧客.csv" というファイル名で保存すれば、Excel 等で表として開けます。

JSON形式

{
  "顧客":[
      {"顧客ID":"C003","顧客名":"概 念","住所":"XXX"},
      {"顧客ID":"C172","顧客名":"円 帝一","住所":"YYY"},
      {"顧客ID":"C026","顧客名":"蔵巣 抽","住所":"ZZZ"},
    ・・・
  ]
}

を、”顧客.json” というファイル名で保存すれば、何らかのアプリケーションで表現フォーマットを与えれば、表としての表示が可能です。

ストレージに保持されたデータ=概念インスタンス群)=ツイン

電子化した情報を、開発するITシステムに求められる非機能要件を元に選定された、ストレージやデータベース等に格納し、現実の世界の概念インスタンスに対応するエンティティの変化を元に、格納された情報を更新し続ければ、今、“ビジネスはどうなっているか”という状態が、ITシステム上に保持され、保持されている情報は、概念情報モデルの定義に従って、問合せることにより、全て取り出すことができます。この仕組みにより、ビジネスにおいて、

- 事実に基づいた状況確認
- 事実に基づいた状況判断

が可能になります。

加えて、ある特定の初期状態を仮定して、一定のルールのもとにビジネスを展開したらどうなるかを調べるためのシミュレーションも可能です。
デジタルツインは、「現実世界のモノやコト、役割の情報をデータ化し、ITシステム上で“写し=ツイン”を持ち、ツインに基づいて、状況確認や状況判断を行う」のが基本コンセプトでした。
概念情報モデルの“概念インスタンス”をデジタル化したものが、正に“ツイン”であり、概念情報モデリングは、デジタルツインの実現環境構築において欠かせない作業です。

現実世界、デジタルツイン、概念情報モデルの関係を参考までに図示しておきます。

画像5
図5. ストレージに保存された概念インスタンスとアプリケーションの関係

値が確定した特徴値

下図のような、快適な居住空間を主題領域とした、部屋という概念クラスを考えてみます。

図6. 個々の部屋に対応する概念インスタンスと、その分類・雛形としての概念クラス

部屋という概念クラスについても、前のセクションと同様に、表形式で現実世界に存在する個々の部屋の概念インスタンスの状態(概念クラスに紐づけられた特徴値が値をもっている)を表現可能です。
部屋の温度という特徴値について、まず考えてみます。
概念情報モデルをもとに、現実世界の在り様を反映した概念インスタンスとリンクを記述した時(これは表形式で表現した時に一致する)、概念インスタンスの特徴値は値が確定していなければなりません。値が確定しているという事は、ある部屋の温度が、例えば、19.3℃ や 25.7℃ 等という具体的な値だという事ですね。

さて、この値はどうやって得られたのでしょう?
この問いに対する答えは、”気にしなくてよい”です。
概念モデリングにおいては、その仕組みは一切考慮しなくて構いません。現実の部屋に昔ながらの温度計が設置されている様を思い浮かべてください。あなたがその温度を必要とした時点で、その温度計を観察すれば、温度は確定していますよね。昔ながらの温度計ではなく、温度を感知するセンサーが組み込まれた温度をデジタル表示してくれる機器の場合でも、事情は一緒です。概念情報モデルをもとに、現実世界の在り様を反映した概念インスタンスとリンクを記述することは、あなたが、現実世界を観察し、スナップショットとして世界を認識することと同じです。単にその時点の温度を知りたいだけであれば、それで十分でしょう。
例に挙げている部屋という概念クラスについていえば、他の明るさや湿度、CO2濃度、使用電力量といった特徴値もまた、同様に考えて構いません。

このように、概念情報モデルで定義する特徴値には、その特徴値の意味によって、暗黙的に値が確定するものもあるのだということを留意して概念モデリングを行うとよいでしょう。
…ここで説明を止めてしまうと、豊富な経験をもつソフトウェア技術者、特に、機器制御の仕組みを作っている様な組込み技術者は、気になって気になって夜も眠れなくなってしまうかもしれませんね。
当然のことながら、作成した概念モデルを基に、実装プラットフォーム上で実際に動作するソフトウェアを作成する時点では、どうやって特徴値の値を確定・更新するのかを考慮しなければなりません。当たり前の話ですね。
概念モデリングにおいては、その仕組みは、実装する時に必要になる主題領域で取り扱うトピックであって、快適な居住空間という主題領域には含まれないと考えているので、考慮しなくてよい、という風に考えるよ、という事です。快適な居住空間という主題領域においては、温度を測る仕組みよりも、精度や分解能、計測頻度が扱うべきトピックになります。

概念情報モデルのテスト

3. モデリングとは ~ 現象学からの考察」に書いている様に、現実世界を正確に記述した概念情報モデルがアプリオリに存在することはありません。モデル作成者が作成した概念情報モデルは、あくまでも作成者がモデル化対象の現実世界に関する様々な情報を咀嚼し理解した知識体系を、概念情報モデルの記法や流儀に従って、図示化したものです。
出来上がったモデルが正確にモデル化対象世界を記述しているかどうかの絶対的な判断基準は存在しません。
たとえ、本稿を含む一連のドキュメントに記載の記法や作法、流儀を忠実に守って概念情報モデルを作成したとしても、対象世界から拾い上げるべき概念の抜け漏れが少なくなることはあっても、単に概念情報モデル図の文法的な正しさが保証されているだけにすぎません。
作成したモデルの正しさは、その対象世界や開発活動に関わるステークホルダー達と共に、以下に述べる手順で検証し、全員の合意を得ることによって保証します。

検証作業は以下の様に進めます。

  1. 対象世界の主要なシーンを少なくとも3つ想定する

    • 各シーンで起こりうるシナリオや事項を文書や模式図(ポンチ絵)で記述する

  2. 各シーンごとにシナリオや模式図に出てくる、モノ・コト・役割全てについて、以下をチェックする

    1. その雛形となる概念クラスや、関係:Relationship が存在するか

      • 存在すれば OK

    2. 概念クラスで定義された特徴値が全て値を持つか

      • 値があれば OK

    3. 関係:Relationship の多重度を満たすか

      • 満たしていれば OK

検証作業の途中で、チェックを満たさない、モノ・コト・役割があれば、チェックを満たす様に、概念情報モデルを修正しましょう。
概念情報モデルを構成する概念クラス群は、関係:Relationship で連鎖しています。小手先の修正は、多重度や意味の連鎖を壊す恐れがあります。修正は、検証途中で見つかった問題に対して、都度都度直すのではなく、問題点をある程度見つけた時点で、概念情報モデルの全体を見渡しつつ、注意深く修正する事をお勧めします。

モデル化対象世界を記述する概念情報モデル

ここで今一度、概念情報モデルについて振り返りを行います。
0. 概念モデルとは」で説明したように、概念情報モデルは、モデル化対象世界(ドメイン)の在り様を規定する、語と図で記述したモデルです。
ここで注意が必要なのは、概念情報モデルで記述される、概念クラス、特徴値、関係(Relationship)は、モデル化対象世界(ドメイン)を構成している何かと1対1対応にはないという点です。

概念情報モデルの説明の前に、先ずは、基本的な事項を確認していきましょう。

1対1で対応するモデルと、スキーマとしてのモデル

現実世界を記述するモデルの基本は、記述されたモデルを構成する要素が、現実世界を構成する何かと、双方向で1対1でなければなりません。

図7. 現実世界のモデル化の必須要件

詳細は、”概念モデリングに関する圏論的考察”を読んでほしいのですが、数学の一分野の圏論の用語を使うと便利なので、ここではその様な形で説明していく事にします。現実世界を記述する圏を圏Wと呼び、モデル化された世界を記述する圏を 圏I と呼ぶことにします。圏論的には、圏W と 圏I は自然同値であるといいます。すごく簡単に言うと、自然同値であれば、圏I で成り立つことは圏W で成り立つことが保証されます。ただし、これは、現実世界を概念モデルとして記述したら、自然に自然同値なモデルができあがるという意味ではなく、自然同値になるように圏I のモデルを作成しなさい、というモデリングに対する要求になります。

概念モデリングにおいて、圏I の要素になるのは、まず、概念インスタンスです。

図8. 概念インスタンス

概念インスタンスは、モデル化対象世界において、個別に区別できて、かつ、単体として存在しているものと、双方向で1対1の対応関係を持ちます。
次は、概念インスタンスにひもづく、値が確定した特徴値と、その値を規定するデータ型です。

図9. 値が確定した特徴値とデータ型

値が確定した特徴値は、概念インスタンスと同様、個別に区別できる存在ではあるのですが、それ単体では存在し得ず、どれか一つの概念インスタンスに紐づいて存在するものです。加えて、その値は、対象世界において意味づけられた単位や値域を持っています。それがデータ型です。
値が確定した特徴値もまた、モデル化対象世界に存在しているものと双方向で1対1の関係を持ちます。
次は、対象世界において、モデル化された世界の2つの概念インスタンスに相当するものの間に、対象世界において何らかの意味的なつながりを持っ場合、それを、リンクとしてモデル化します。

図10. リンク

モデル化対象世界に存在する、単体で存在して、かつ、個別に区別できるもの(概念インスタンスに対応)の間に存在する意味的なつながりもまた、個別に区別できるものであり、モデル化された世界のリンクと1対1に対応します。
以上を図にまとめます。

モデル化対象世界とモデル化された世界の対応関係※ ”事象”についての詳細は、振舞モデルの解説を参照のこと

現実世界(モデル化対象世界)に存在するものは、モデル化された世界における

  • 概念インスタンス

  • 概念インスタンスに紐づいた、値を持った特徴値

  • 特徴値の値を規定するデータ型

  • 二つの概念インスタンスを意味づけるリンク

のどれかと1対1対応することになります。

ここで一つ注意をしておきます。説明の中で、モデル化対象となるドメインの事を、現実世界と呼んだり、モデル化対象世界と呼んだりしていますが、現実世界という用語を使った場合でも、その対象世界の範囲は、あなたが存在していて、かつ、あなたを取り巻いている現実世界全体ではないことに、ご注意ください。ここで言っている現実世界モデル化対象世界)とは、あくまでも、モデリングを行いたい観点で観察できる範囲、つまり、ドメインの範囲であり、モデル化による抽出は、目につくありとあらゆるものを抽出するのではなく、目的用途にそったものだけ、抽出しなければなりません。

さて、圏W圏I が1対1対応するという事は、現実世界が変われば、作成したモデルも変わるという事を意味します。つまり、現実世界を1対1で記述するモデルは、現実世界が変化するごとに、変更しなければなりません。

圏I のモデルの例

モデルを描いたそばから変更し続けなければならないとしたら、それは地獄以外のなにものでもないでしょう。それをモデル作成者に強いるのはナンセンスであり、安定したものを基盤に作業を進めることは、効率よく作業を進めるための鉄則です。
そういう理由から、概念モデリングにおいては、圏I のモデルを中心に据えるのではなく、圏I を分類したモデルを作成することに注力する訳です。

変化しやすいモデルを分類し安定したモデルを作成する

モデル化対象世界において、同じ意味を持つかどうかで分類を行い、

  • 特徴値の値を規定するデータ型 ⇒ データ型

  • 概念インスタンス ⇒ 概念クラス

    • 同じ意味を持った存在で、かつ、同一の特徴値の組をもつこと

  • リンク ⇒ 関係(Relationship)

    • 同じ意味を持ったつながりで、かつ、概念クラスが同じであること

で、概念クラス関係(Relationship)を抽出します。概念クラス関係(Relationship)で構成されたモデルの事を、概念情報モデルと呼び、図で描いた概念情報モデルのことを、概念情報モデル図と呼ぶわけです。概念情報モデルで記述されたモデルのことを、圏C と呼ぶことにします。
圏C が出来上がったあとは、圏I のモデルは、圏C モデルで記述された定義に規定されることになります。

  • 概念インスタンス

    • どれか一つの概念クラスを雛形として存在する

    • 雛形である概念クラスに定義された全ての特徴値の値が確定していなければならない

  • リンク

    • どれか一つの関係(Relationship)を雛形として存在する

    • リンクで紐づけられた概念インスタンスは、

      • 双方向で、関係(Relationship)で定義された意味において紐づけられていなければならない

      • 双方向で、関係(Relationship)で定義された多重度を満たしていなければならない

このような 圏C のモデルのことを、圏Iスキーマのモデルであるといいます。圏W圏I は自然同値、つまり、1対1対応なので、概念情報モデルは、結果として、圏I のモデルのスキーマであるだけでなく、圏W つまり現実のモデル化対象世界の在り様を規定するスキーマのモデルである、ことになります。
概念モデリングにおいて、このことは常に意識して、概念情報モデルを作成しなければなりません。初学者の多くは、この区別がつかず、圏I(つまり、対象世界と1対1)のモデルのレベルの概念情報モデルを作ってしまいがちです。概念情報モデルのテストにおいて、頻繁にモデル図の変更が生じるような場合は、スキーマとしての概念情報モデルを作っているか、確認してみるのが良いでしょう。

概念情報モデルで命題文を構成する

現実世界のスキーマとしての概念情報モデルは、命題論理文におきかえることができます。
概念インスタンス、概念クラス、特徴値を考えてみます。
ある概念インスタンスを ii の雛形となる概念クラスを c とし、c の特徴値を {p} と書くことにします。このとき、

  1. c は {p} で特徴付けられている

  2. ic である

  3. i は {p} の値を持つ

という命題文を構成できます。このとき、圏I のモデルの構成要素である i は、現実世界の圏の 圏W 上に対応する要素がただ一つだけ存在することが、圏I が現実世界を記述するモデルであることの条件なので、この命題文は、有意味でかつ でなければなりません。
参考までに付け加えておくと、命題が無意味になる場合は、モデル化対象世界において、概念情報モデルをもとに構成した命題文が意味をなさない頓珍漢な文章(一昔前のAIが生成していた不自然な文章など)になっていることを指します。有意味でかつの場合は、構成した命題文は意味をなすものの、その命題文に相当する何かがモデル化対象の現実世界に存在しない状況を指します。

同様に、あるリンクを lk、その雛形となる関係(Relationship)を r とし、そのリンクでつながっている二つの概念インスタンスをそれぞれ、lk_illk_ir とし、r の両端の意味をそれぞれ、rr_lrr_r、多重度をそれぞれ、rm_lrm_r とします。このとき、

  1. lk_il は、lk_irrr_r である

  2. lk_ir は、lk_ilrr_l である

  3. ひとつの lk_il に対する rr_r でつながっているリンクの数は、rm_r を満たす

  4. ひとつの lk_ir に対する rr_l でつながっているリンクの数は、rm_l を満たす

という命題文が構成できます。こちらも、現実世界に対して、有意味でかつ でなければなりません。

ついでに、Super-Sub 関係(Relationship)についても言及しておきます。Super‐Sub 関係(Relationship)を r とし、Super 側の概念クラスを cb、Sub 側の概念クラスを、cs1cs2、…とし、それぞれの概念クラスを雛形とする一つの概念インスタンスをそれぞれ、ibis1is2、…とします。このとき、有意味でかつでなければならないのは、

  1. 任意の ib は、is1is2、…のどれか必ず一つと r の意味においてリンクが存在する

  2. 任意の is1is2、…は、必ず、r の意味において、それぞれ一つづつ対応する ib とのリンクが存在する

という命題文です。簡単なことを複雑に書いているようで恐縮ですが、概念モデリングにおいては、モデル化された圏I の世界においては、Super-Sub 関係(Relationship):r にある二つの概念クラスを雛形にした概念インスタンスは、Sub 側の概念インスタンスだけが存在すると考えるのではなく、あくまでも、Super 側の概念インスタンスも存在していて、r を雛形にしたリンクでつながっている、と考えることを忘れないでください。

この命題文構成に関する考え方も、概念情報モデルの妥当性のテストを進める時のポイントの一つです。

また、概念情報モデルが命題文を構成できるということは、論理を展開するさいの基盤として概念情報モデルを利用できることを意味します。よって、厳密な論理を展開してものごとを推論してく、クリティカルシンキングを遂行する場合にも役立ちます。クリティカルシンキングを一般的な文章で行う場合、複数の文章を合わせて推論を行う事になりますが、文章の間の関連を見落としがちです。概念情報モデルでは、概念クラス群は関係(Relationship)によって連続して連なっているので、見落としを防ぐことができます。加えて、日本語の特性上、どうしても、文章の中で数詞が曖昧になってしまいがちですが、関係(Relationship)に明確な多重度が定義されていることにより、数詞の曖昧さを排除可能です。

命題文の構成についての詳細な説明は、”概念モデルの言語論理学からの考察 ~ Frege、Russel、Wittgenstein”で解説しているので、そちらも参考にしてください。

概念情報モデルの使い方に関する解説は以上です。次は、「概念情報モデルの操作」で、概念情報モデルに対する様々な操作を解説します。


いいなと思ったら応援しよう!