【連載】概念モデリングを習得しよう：意味の場の状態をモデルで記述する（第4回）

これまでの記事で、モデリングは、モデル化対象を認識し、記述することだとお話ししてきました。また、

●現象学による人間の認識の基本

●人間の思考は言語を前提とする

●言語哲学における文脈原理

●存在は意味の場に現出する

は、人間の思考の基本であり、概念モデリングだけでなく、モデリング全般の基礎であると述べました。

従って、モデル化対象の世界に対して、人間は、ある意味の場において、認識を行い、言葉を前提とした記述を行う、ということになります。

現象学における存在認識の基本は、フッサールが考察のために例示しているリンゴや、ヘーゲルの白い塩など、

●複数の性質を持つ事柄

です。

コンピューターグラフィックスなどでリンゴや塩を描画する技術を対象としたモデリングは例外ですが、リンゴや塩を実際に販売、栽培、生産する意味の場においては、リンゴや塩が何の脈絡もなく虚空に浮かんでいることはあり得ません。リンゴであれば皿に載っていたり、箱に収められていたり、塩であれば小皿に盛られていたり、袋に入っていたりします。

皿や箱、袋もまた、何らかの性質を持った事柄であり、リンゴが皿の上に置かれている、あるいは、塩が袋に入っているというように、なんらかの２つの事柄が、なんらかの意味的な関係でつながっています。

まとめると、現実世界に存在する

●事柄

●事柄の特徴

●事柄の間の意味的なつながり

を、意味の場を通じて、識別し、数え上げながら認識することが、われわれの思考を支える認識の基盤であり、この3種類を記述することが、状態の記述の基礎になります。

概念モデリングで作成する概念モデルは、この3つを拾い上げて記述することを基本とします。概念モデリングでは、それぞれを

●事柄 ＝ 概念インスタンス（Conceptual Instance）

●事柄の性質 ＝ 概念インスタンスの特徴値（property）の組

●事柄の間の意味的なつながり ＝ 概念インスタンス間のリンク（link）

という用語で呼んでいます。

例に挙げた、皿に載ったリンゴを図で描くと、

こんな感じです。

リンクの両端には、それぞれの事柄の反対側から見た意味を示す文を添えることにしています。

図には3つの例を挙げています。それぞれ特徴値とリンクの両端のテキストが違っているのは、それぞれに付記した意味の場にふさわしいと思われる特徴値とリンクの意味を抽出した上で記述されているからです。

リンクの両端に添えたテキストは、両端の概念インスタンスと組み合わせて述語文を作ることができます。

例えば、果物屋は、

●リンゴは皿で売られている

●皿はリンゴを陳列している

のように、テキストの最初の“～”を反対側の概念インスタンスに、二番目の“～”を添えた側の概念インスタンスに置き換えて読み下します。

“～は～を区別している”というようなテキストは冗長に見えてしまいますが、英語にすると、“～ distinguishes～”になり、うまい具合にテキストの両端に、2つの概念インスタンスが収まるようになっています。冗長に見えてしまうのは、日本語の文法上の制約と思ってください。しかし、図で描く場合、この形式だと白地を圧迫してしまい、見苦しい図になってしまいがちなので、以降に示す図では、“てにをは”が容易に想像付かない場合を除き、“～は～を”などは省略することにします。

オブジェクト指向プログラミングに精通している読者であれば、事柄＝概念インスタンスは、プログラム上のclass をひな型にしたinstance と、事柄の性質＝概念インスタンスの特徴値の組は、そのinstanceのメンバー変数（プログラミング言語によって名称は異なる）として、事柄の間の意味的なつながり＝概念インスタンス間のリンクは、その instance の他の instance を参照するメンバー変数として思い浮かべるでしょう。しかし、このコラムを読み進める上では、オブジェクト指向プログラミングに関する知識は、邪魔になるのでいったん脇に置くことをお勧めします。

オブジェクト指向プログラミングのメンバー変数には、private、protected、public等、その変数へのアクセスの範囲を指定する仕組みがあります。けれども、概念モデリングでは、そのような範囲指定はありません。概念モデルの全ての特徴値は、その意味の場において認識・識別されたものであり、論理的帰結として、全ての特徴値は観察可能です。

オブジェクト指向プログラミング風に言うならば、概念モデルの特徴値は全て public であるということです。また、オブジェクト指向プログラミングにおける instance が他の instance を参照するメンバー変数を持っていて、その変数が、概念モデリングにおけるリンクを表すとしても、それは単にオブジェクト指向プログラミングの仕組みを使っているだけです。リンクを記述するのに必要な両端のテキストを表現する仕組みがオブジェクト指向プログラミングにはありません。

オブジェクト指向プログラミングは、その名前の通り、オブジェクト（事柄＝概念インスタンス）に着目します。概念モデリングも、もちろん、オブジェクトと同等の概念に着目はしますが、事柄間の意味的なつながり＝リンクの方をより重視します。

なぜなら、言語哲学的観点からすれば、事柄（概念インスタンス）の意味を規定するのは、事柄そのものというよりも、むしろ、事柄間の意味的なつながり（リンク）であるからです。

実際の概念モデリングでは、図に挙げたような、たった２つの概念インスタンスと、ただ1つのリンクしかないようなモデルはまれです。

例として、果物屋における商品販売と、果樹園におけるリンゴ栽培という意味の場の状態を、特徴値を伴った概念インスタンス群とそれらの間のリンクを使って図示します。

図表1では、見栄えを考えて省略していましたが、値に単位がある特徴値の場合は、値のすぐ右横にその単位を記載し、その右横に“:”で区切って、その特徴値の名前を表記しています。

また、あるリンクを指して、それを説明する時の便宜を考えて、それぞれのリンクに Ln（nは自然数）という識別用の名前を付けています。他に、特徴値のうちの幾つかには、“{}”でくくった識別子や参照などを表す添え字を付けているものがありますが、これらは後で詳しく解説するので、ここでは雰囲気だけつかんで読み流してください。

図表2と3には、現実の意味の場をイメージしやすいように、絵を添えています。その絵とモデル図を見比べると、モデル図の方は現実の意味の場のごく一部しか抜き出していないことが分かるでしょう。本来であれば、意味の場の状態をモデルとして記述する場合、全ての特徴値と概念インスタンス、リンクを抽出して記述するのが概念モデリングの基本ではあるのですが、この記事のスペースでは、全部はとても書ききれないので、一部分のみを記述していると理解してください。

また、図表2と3では、概念インスタンスを、それぞれが指す現実の意味の場の事柄を想像しやすいようなアイコンで表現しています。概念モデリングでは、例えば概念インスタンスを長方形で表現するような図で描いても構いません。

参考までに、図表2で描いた果物屋のモデル図について、別の形式で描いたものを図表4に挙げておきます。

概念モデリングでは、意味の場の状態を記述する時の表現方法は、モデルを作成する目的に応じて、図以外にも、表やテキストなど、見やすい、あるいは扱いやすい方法を選択すればよいとしています。概念インスタンスやリンクが多過ぎて（実際のモデリングでは常にそうなのですが）、図に描くのが難しい場合は、表や JSON（JavaScript Object Notation、JavaScriptの一部をベースに作られた軽量のデータ交換フォーマット） 形式のテキストで記述しても構いません。

実のところ、概念モデリングにおいては、意味の場の状態を表すモデルの描き方について、正式な記法は規定していません。モデリングというと、全て図で描かなければならないと思っている読者がいるかもしれません。しかし、モデリング本来の目的は、きちんと意味付けされた項目の抽出です。見栄えは、モデルを利用する用途に合わせ、他人が見たときに誤解が生じない程度の記法のルールが決められていれば十分です。この記法のルールのことを一般的に、“シンタックス（Syntax）”と呼び、項目の抽出における意味付けのルールのことを、“セマンティクス（Semantics）”と呼びます。概念モデリングにおける状態の記述のセマンティクスは、

●概念インスタンス

　▷事柄を示す

　▷概念インスタンスの性質を示す、値が確定した特徴値がひも付けられている

　▷特徴値は名前と単位を持つ

●リンク

　▷2つの概念インスタンスの間の意味的なつながりを示す

　▷両端に、それぞれの概念インスタンスから見た、つながりの意味を示す述語を伴う

です。セマンティクスにのっとって抽出された、意味の場の状態が、例えばNoSQL データベースに格納されていると想像してみてください。状態を記述したモデルは、ITシステムのデジタル空間上に確実に存在しているのは間違いありません。データベースへの状態の保持において、重要なのはセマンティクスであり、その状態をアプリケーションで参照する時点で、それを具体的に表現するのにふさわしいシンタックスが決まります。

例示してきたモデルは、モデル化対象の意味の場の、時々の状態のスナップショットを記述しています。果物屋のモデルを例にすると、ある時点において

●リンゴが何個存在するか

●ある特定のリンゴの重さは何グラムか、または、いくらで販売されているか

●そのリンゴが陳列されている店はどこか

●その店の売上高はいくらか

という問いに対して、モデルに記述された「概念インスタンス」「概念インスタンスにひも付く特徴値」「概念インスタンス間のリンク」をたどって答えることができます。

また、モデル化の対象は、現実世界に対する意味の場であり、モデルはその切り取りです。なんらかの出来事の発生などで、現実世界のありさまが変化した時には、その切り取りである写しとしてのモデルの記述もまた、その変化に対応した更新が必要です。

モデルの記述において現実世界の変化は、

●概念インスタンスの生成・削除

●特徴値の変化

●リンクを張る・切る

で表現します。

現実世界に発生する個々の出来事は、その性質をそのまま記述する特徴値（property）を伴う“事象（event）”としてモデル化する場合と、並行して、あるいは同時に、特徴値の組を伴う概念インスタンスとしてモデル化する場合があります。

事象をモデル化する場合は、その事象が、

●モデルに既に存在している、どれか1つの概念インスタンスにひも付く

●その事象をきっかけに、1つの概念インスタンスが新しく生成される

のどちらかであると考えます。

出来事という言葉を聞いたときの脳内イメージは、読者それぞれだと思います。概念モデリングにおける出来事とは、人為的に発生し得るもの、突然起こる自然現象、何らかの物理法則により連続的な変化を引き起こす時間経過など、モデルの更新のきっかけとなるもの、全てを指します。

この記事を読んでいるソフトウェア技術者の中には、モデルの記述がデジタル空間上でデータとして保持されていて、何らかのコンピューティング処理によって、データが更新される、と暗に思っている人がいるかもしれません。そのような発想は一切捨ててください。

概念モデリングは、現実の意味の場で起こっている様を、ただ、淡々と拾い上げて記述するだけで、なぜ、その出来事が生じるのか、なぜ、現実世界が変わっていくのかなど、その仕組みを問うたり、解明したりすることには一切立ち入りません。

なぜ、現実世界が変わっていくか、その根本的な原理は、哲学的にも自然科学的にも未解明なのですから。一方で、このような態度は、常日頃から解決策や実装手段を考えるのにたけたソフトウェア技術者を、とても不安な気持ちにさせてしまうかもしれません。

「目先の問題に対して、手っ取り早く解決策が得たいだけなんだよ」と。そんな考えを持つ方は、今一度、このコラムの第1回を読み直してみてください。現状と理想の状態を正しく認識し記述できること、それが問題を解決するための大前提であり最重要項目です。「そういわれてもねぇ…」と、今思ったあなたへ。この連載の最後の方で、記述した一連の概念モデル群を、実際に動く IT システムに実装していく方法を解説するので、安心して読み進めてください。

次回は、概念モデリングを数学的な観点から解説していきます。