【連載】概念モデリングを習得しよう：“is-a”リレーションシップと特徴値による意味の厳密化（第13回）

筆者のこれまでの観察によると、概念モデリング初心者は、矢印のような線をやたらと使いたがるようです。概念情報モデルの作成時、強い制約を表明するis-a のリレーションシップは十分に注意して使いこなしましょう。

“is-a”のリレーションシップは、オブジェクト指向プログラミングに慣れた読者には、継承（inherit）に見えてしまうかもしれません。しかし、まったく別物だと考えてください。継承の場合、子クラスのインスタンスと親クラスのインスタンスは一体ですが、概念情報モデルでは、単に子側のインスタンスと親側のインスタンスが一つのリンクでつながっているだけです。概念モデリングでは、一つの概念クラスが、複数の“is-a”のリレーションシップの子側になるモデルを許しています。オブジェクト指向プログラミングの場合、それは多重継承に見えて、メンバー名のバッティングなどいろいろな弊害を生じてしまいます。ですが、概念情報モデルの“is-a”は、前述の定義により、特徴値の名前のスコープはそれぞれの概念クラスに属するので、そのような問題は生じません。

逆に、一つの概念クラスが、複数の“is-a”のリレーションシップの親側になるようなモデルは、二種類の分類の観点が一つの概念クラスに混在してひも付くことになってしまい、意味の場における概念があいまいになってしまうので禁止としています。概念情報モデルの概念クラス群は、それぞれ独立した意味が切り出されていなければなりません。

また、オブジェクト指向プログラミングにおける継承の宣言が、再利用を原理として、それぞれ独立していて無関係なのに対して、概念情報モデルの“is-a” のリレーションシップの子側の概念クラス群は、そのリレーションシップが表す分類の観点で束ねられていることを頭にたたき込んでください。

参考までにですが、オブジェクト指向プログラミングにおいても、概念情報モデルの is-aと同じで、初学者は、継承をやたらと使いたがる傾向にあるようです。オブジェクト指向プログラミングにおける継承もまた別の意味でサブクラスに強い制約を課すので、使う場合は十分注意しましょう。

特徴値（Property）は、モデル化対象の意味の場から拾い上げて抽出・分類した“事柄の性質”を表します。

特徴値は、必ず一つの概念クラスにひも付くので、概念クラスに従属した形で定義されます。繰り返しになりますが、モデル化対象の意味の場の状態の写しである圏Iのモデル上に記述された概念インスタンスの特徴値は値が確定していますが、概念情報モデルの概念クラスにひも付いた特徴値は、それを分類・整理したものであり、データ型で値が規定される変数です。

特徴値は、

• 名前
• データ型
• 制約
  ＞識別子、および、その識別子のレベル
  ＞リレーションシップの参照
  ＞算術的特徴値
• 概要説明文

で定義します。同じ概念クラスにひも付く特徴値の名前は全て異なっていなければなりません。

圏Iのモデルでは、参照を表す特徴値に、リンクの名前が書かれていましたが、概念情報モデルでは、意味的つながりは、リンクの分類であるリレーションシップで記述されるので、リレーションシップの名前が添え字として使われます。

図で表記する場合には以下のようになります。

以前、圏Iのモデルの特徴値で、算術的な特徴値を紹介しました。

概念情報モデルでは、果樹木のあるインスタンスに Rx でひも付いているリンゴの数を数え上げれば、特徴値である“”の値が計算で算出可能です。圏Iの場合は計算方法が場当たり的でしたが、概念情報モデルでは明確な算出ルールの定義が可能になっています。

概念クラスの特徴値の概要は、それが変数であることを除き、すでに第8回目の記事で解説した圏Iのモデルにおける特徴値と基本的に同じです。重複する部分は割愛することにし、ここでは、分類・整理した結果生じる項目についてのみ解説しています。

概念クラスにひも付いた特徴値は、意味の場において、その概念クラスをひな型として存在し得る概念インスタンス（＝事柄）が持つ性質を規定し、それぞれの特徴値は、事柄の性質の一面を表現します。意味の場における事柄がどんな性質を持っているかによって、その事柄の意味が決まるので、特徴値は、概念クラスが何を指しているか、その意味を、具体的かつ明確にするものです。概念クラスは、それにひも付く特徴値の組とリレーションシップで意味が定義されると覚えてください。

特徴値とリレーションシップをうまく使うことによって、意味の場における事柄の存在条件を、より厳密に記述することが可能です。

例として、工場の製造ラインに並んだ製造装置をモデル化した、以下の概念情報モデルを見てみます。

“製造装置”という概念クラスの“製造ラインID”という特徴値の右横に参照の名前が二つ添えられているモデルになっています。

これは、R2とR3それぞれの参照を表す特徴値を一つの特徴値でまとめたものであり、まとめることにより、一つの製造ライン上に並んだ製造装置の列の中に、異なる製造ライン上に設置された製造装置が紛れ込む余地を排除しています。

このモデルが出来上がるまでの変遷を下図に示します。

フェーズ1のシンプルなモデルの“製造装置”の特徴値の組だけでは、別の“製造ライン”の“製造装置”が紛れ込んでしまう可能性を排除できません。フェーズ2では、それを防ぐために、”製造装置“の第一位の識別子を {製造装置ID} から {製造装置ID, 製造ラインID} に変更し、その変更を受けて、R3 の参照を表す特徴値を {次の製造装置ID, 次の製造ラインID}（R3でリンクされる製造装置の製造装置IDと製造ラインIDの値を保持）に変更されています。最終段階、つまり、図表4と同じフェーズ３のモデルでは、R2 の参照を表す”製造ラインID“と、R3の参照の一部を表す”次の製造ラインID“を合体させ、同じ値しか持てないようにして、同じ製造ライン上の装置しか R3 のリンクを作れないようにしたわけです。

“製造ラインID”と“次の製造ラインID”を一つの特徴値にまとめることにより、意味の場としてあり得ない存在状況が生じる可能性が排除され、対象世界をより厳密、かつ正確に記述するモデルになっています。

このことは、作成した概念情報モデルを使って IT システムを構築するときに威力を発揮します。意味の場の状態をリレーショナルデータベースで保持する場合、曖昧な概念情報モデルを使ったときには、保持されたデータの入力・参照で、正しいデータがどうかのチェックを行うロジックが必要です。一方で、厳密な概念情報モデルの場合は、そもそも間違ったデータを保持することができないので、正しいデータのみしか保持しないことから、チェックロジックは必要ありません。結果として、ロジックの設計・実装作業が不必要になるだけでなく、バグが入り込む余地やテスト項目も減り、テスト・評価工程の工数が削減され、品質も向上するという利点を生み出します。

概念情報モデル図のような、四角と線で構成されるモデル図を作成する際、とかく、四角とその名前にのみ注意が行きがちです。だからこそ、概念モデリングにおいては、四角で表現される概念クラスの存在意味を規定するのは、それにひも付けられた特徴値の組とリレーションシップの組で在ることを忘れないでください。

モデル作成者が、モデル化対象の意味の場を通じてその世界をどう認識し、不明な部分をどう補い、細かい部分をどう判断したかを記述し他人に表明する、それが概念モデルです。

あまり頭を働かせず、適当に四角を書いて名前を付け、四角の間に適当に線を引いたような絵は、モデルとは呼べるものではないことを肝に銘じましょう。

データ型（Data Type）は、特徴値（Property）が取り得る値を規定するデータの型を、モデル化対象の意味の場から拾い上げて抽出・分類したものです。

圏I のモデルでは、概念インスタンスの性質の一面を記述する確定した値を持つ特徴値のそれぞれについて、データ型を定義していました。概念情報モデルは、それらを整理・分類し、概念情報モデルに記述された全ての特徴値で共有されるものとして定義されます。

第8回で圏Ｉのデータ型でほぼ説明は尽くしているので、詳細はそちらを見ていただくことにして、概念情報モデルにおけるデータ型の定義について列記しておきます。

データ型は、

• 名前
• 基本型
  ＞文字列、自然数、実数、日時、識別子
• 単位：オプション
• 値域：オプション
• 概要説明文

で記述するのが基本です。

圏Iのモデルで説明したように、地球上の位置を表す緯度、経度の組、2次元以上の速度や加速度などのベクターなど、基本型のデータ型を複数組み合わさった複合型や、名前の付いた有限の項目（列挙子）のみ値として許される列挙型も、データ型として定義し、特徴値のデータ型として利用が可能です。

データ型の名前を決める際には、モデル化対象の意味の場において適切な名前を、頭を振り絞って考え抜いて決めるようにしましょう。データ型は、それが規定する特徴値が、何の性質を表現するかを表す重要なファクターだからです。

以上で、概念情報モデルに関する詳細な説明が一通り終わりました。

前に言及したように、概念情報モデルは、一度作成したらそれで終わりということはありません。人間とは誤解したり間違ったりする生き物ですから、出来上がった概念情報モデルが、モデル化対象の意味の場を正しく記述している保証はないからです。

概念情報モデルは、以下のテストを行い、抜け漏れ、間違い、勘違いを探し、発見した問題への対応を繰り返します。

• スケッチや圏Iのモデルに出てくる事柄や意味的つながりを、概念情報モデルで記述された概念クラス、リレーションシップをひな型とするインスタンスとして表現できるかチェックする
• ステークホルダーが思い描くストーリーやシナリオをインタビューし、抜け漏れがないかチェックする
  ＞双方が使っている単語の意味が合っているか
  ＞多重度は特に徹底的に確認する

概念情報モデルの改変は、問題を発見するたびに行うと全体の整合が取れていないモデルになってしまいがちです。発見した問題点ごとに細かく行うのではなく、ある程度問題点をまとめてから、修正するのが良いでしょう

次回は、概念情報モデルと圏Iのモデルとの関係について解説します。