106. 概念情報モデルの見直しと状態作成・操作のアクション記述

前回の記事　　　　　　　　　　　　　　　　　　　　　　　　次回の記事

はじめに

前回作成したモデルをレビュー結果をもとに書き換えた結果を説明し、その概念情報モデルに沿った圏I のモデルを構築・操作するためのアクションを作っていきます。

見直し後のモデル

見直しポイントは、以下の二項目です。

• 英語と日本語の混在

  • 識別子など形式的なものは除き、日本語に統一する

• 一般化

  • 歩行解析だけでなく医療機器を使った計測もすべて含めるようにする

結果出来上がった、概念情報モデルは、

見直し後の概念情報モデル

となりました。前回の記事のモデルと比較して、どこがどう変わっているか確認してみてください。前のモデルは歩行解析に関する言葉が混じっていましたが、新しいモデルは、歩行解析も含む、”健診受診”という概念ドメインのモデルになっています。
このモデルは、

kae-made/HealthcareCasestudy: BridgePoint Project for Healthcare Casestudy (github.com)

から公開しています。BridgePoint をインストールしている人は実際に開いて確認してみてください。
※ この github リポジトリでも暴露していますが、公開しているモデルをBridgePoint で開くと、リレーションシップの線が崩れてしまう障害が発生しています。現在、xtuml.org に問題報告し、結果待ちです。見苦しくて申し訳ないです。

状態作成・操作アクションの作成

基本を押さえる

5. 概念モデリングに関する圏論的考察 ‐ 議論のとっかかりとして｜Knowledge & Experience (note.com)
で詳しく解説しているように、”健診受診”という概念ドメイン（意味の場）のその時々の状態は、概念インスタンスとリンクで記述される圏I のモデルで記述され、概念情報モデルは、そのスキーマ圏である圏C です。圏C のモデルである概念情報モデルをもとにして、圏I のモデル＝意味の場の状態を記述するということは、概念情報モデルに定義された、

• 概念クラスをひな型にした概念インスタンスの作成

• 概念インスタンスの特徴値の値設定

• リレーションシップをひな型にした概念インスタンス間のリンクの作成

意味の場の状態が変わるということは、既に存在する圏Iのモデル上で、

• 概念インスタンスの特徴値の値が更新される

• リンクが切られたり、張られたりする

• 概念インスタンスが生成されたり削除されたりする

が、それらが概念情報モデルで記述された制約を満たしながら行われることと同義です。制約は、

• 作成される概念インスタンスのひな型となる概念クラスが必ず存在する

• 張られるリンクのひな型となるリレーションシップが必ずある

• 切り貼りされるリンクの多重度がリレーションシップの多重度に合致している

• 特徴値の値が、そのデータ型の値域に収まっている

を意味します。

概念インスタンスの作成

例えば、ある地方でこの健診受診プログラムが運営されていて、会場が二つある状態を記述したい場合は、

• ”地方担当行政部局”の一つの概念インスタンス

  • 特徴値の設定

• ”検診会場”の二つの概念インスタンス

  • それぞれの特徴値の設定

• R3の二つのリンク

になります。

※ ここまで書いてきて、「おや？ちょっとおかしいぞと」いう点をいくつか見つけてしまいました。

• ”検診”、じゃあなくて、”健診”だよな

• R9 の”医師割当て”側の多重度は、”1..*”ではなくて”*”だよな

しれっと、直すことにして話を進めます。なぜそうなのか、読者それぞれで考えてみてください。ちなみに、一つ目は単なるスペルミス、二つ目は意味的におかしい。

圏Iのモデルは、概念情報モデルの記述に従わなければならないので、”地方担当行政部局”の概念インスタンスは単体で作成可能ですが、”健診会場”は、R3 の多重度（地方担当行政部局側）が、1 なので、R3 をひな型にしたリンクでつながった”地方担当行政部局”と、同様な理由で、R4 のリンクでつながった”健診計測器”が最低一つなければなりません。この様子をより正確に書くと、

• ”LGDID”を使って該当する”地方担当行政部局”の概念インスタンスを探す

• ”管理用シリアル番号”を使って該当する”健診計測器”を探す

• ”健診会場”の概念インスタンスを一つ作成する

  • 特徴値を設定する

  • 見つけた”地方担当行政部局”の概念インスタンスと R3 のリンクを張る

  • 見つけた”健診計測器”の概念インスタンスと R4 のリンクを張る

になります。今回は BridgePoint で概念情報モデルを描いてますよね。BridgePoint には、OAL：Object Action Language という概念モデリングのアクションを記述するためのスクリプト言語が定義されています。OAL で上の流れを記述すると、

SELECT ANY lpd FROM INSTANCES OF HC_LGD
 WHERE SELECTED.部局名 == param.部局名 AND SELECTED.所在地 == param.部局所在地 ;

SELECT ANY mcd FROM INSTANCES OF HC_MCD
 WHERE SELECTED.管理用シリアル番号 == param.管理シリアル番号 ;
 
IF NOT_EMPTY lpd AND NOT_EMPTY mcd
	SELECT ANY mplc RELATED BY lpd->HC_MPLC[R3.'運営する'] WHERE SELECTED.会場名 == param.会場名 ;
	IF EMPTY mplc
		CREATE OBJECT INSTANCE mplc OF HC_MPLC ;
		mplc.会場名 = param.会場名 ;
		mplc.所在地 = param.会場所在地 ;
		mplc.責任者氏名 = param.責任者氏名 ;
		RELATE mplc TO lpd ACROSS R3;
		RELATE mplc TO mcd ACROSS R4;
	END IF;
END IF ;

読めばなんとなくわかるかと思います。param.xxx というのは、このアクションを起動するときに供給される引数です。健診会場を一つ用意するには、それを運営する地方担当行政部局が、装備された健診計測器が、それぞれR3、R4 で必要なので、それらを特定する引数が供給されて、それらをもとにそれぞれの概念インスタンスを見つけて、健診会場の概念インスタンスを一つ作成して、引数で供給された特徴値の値を設定して、R3、R4 でリンクする、ということが厳密に書かれています。SELECT や CREATE OBJECT 等で HC_XXX という用語が使われていますが、これらは、概念情報モデルに記載された概念クラスの右上に描かれたキー文字を示しています。

地方担当行政部局を一つ作る場合は、

SELECT ANY lgd FROM INSTANCES OF HC_LGD
 WHERE SELECTED.部局名 == param.部局名 AND SELECTED.所在地 == param.所在地 ;
IF EMPTY lgd
	CREATE OBJECT INSTANCE lgd OF HC_LGD ;
	lgd.部局名 = param.部局名 ;
	lgd.所在地 = param.所在地 ;
	lgd.問合せ電話番号 = param.問合せ電話番号 ;
	lgd.担当メールアドレス = param.担当メールアドレス ;
END IF;

です。前に挙げた概念情報モデルでは、部局名と所在地には特に添え字はありませんでしたが、よくよく考えれば、この二つの特徴値の組は、一意だろうということで、{I2} を添えたことにして上のアクションを描いています。要するに、アクションを起動するときに供給された部局名と所在地がすでに存在する場合、同じ値の組を持つ概念インスタンスは作成できないので、既に存在しているかを確認し、存在がなければ作成するというアクションです。

is-a のリレーションシップを持つ概念インスタンスの作成

次は、R1 という is-a のリレーションシップが定義された対象者、未実施者、被検者の構成を考えてみます。意味の場的には、

1. 未実施者が作成される

2. 被検者に代わる

という手順を踏みます。まず未実施者の概念インスタンスを作成するアクションを示します。

SELECT ANY lgd FROM INSTANCES OF HC_LGD
 WHERE SELECTED.部局名 == param.部局名 AND SELECTED.所在地 == param.所在地 ;
IF NOT_EMPTY lgd
	CREATE OBJECT INSTANCE utgt OF HC_UTGT ;
	CREATE OBJECT INSTANCE t OF HC_T ;
	RELATE utgt TO t ACROSS R1 ;
	t.管理番号 = param.管理番号 ;
	t.氏名 = param.氏名 ;
	t.住所 = param.住所 ;
	t.電話番号 = param.電話番号 ;
	t.生年月日 = param.生年月日 ;
END IF;

次は、未実施者から被検者に代わるアクションを示します。

SELECT ANY lgd FROM INSTANCES OF HC_LGD
 WHERE SELECTED.部局名 == param.部局名 AND SELECTED.所在地 == param.所在地 ;
IF NOT_EMPTY lgd
	CREATE OBJECT INSTANCE utgt OF HC_UTGT ;
	CREATE OBJECT INSTANCE t OF HC_T ;
	RELATE utgt TO t ACROSS R1 ;
	t.管理番号 = param.管理番号 ;
	t.氏名 = param.氏名 ;
	t.住所 = param.住所 ;
	t.電話番号 = param.電話番号 ;
	t.生年月日 = param.生年月日 ;
END IF;

オブジェクト指向プログラミングに慣れた読者には、？って感じかもしれませんが、概念モデリングの is-a のリレーションシップは、継承ではなく、二項リレーションシップの特別な形なので、R1 のリンクをいったん切って、張りなおすという形式で記述します。

他に、医師割当てを行う様のアクションも記述しておきます。ある被検者に対して、医師を割り当てるという流れです。

SELECT ANY lgd FROM INSTANCES OF HC_LGD
 WHERE SELECTED.部局名 == param.部署名 AND SELECTED.所在地 == param.所在地 ;
SELECT ANY d FROM INSTANCES OF HC_D
 WHERE SELECTED.DID == param.DID ;
SELECT ANY tgt FROM INSTANCES OF HC_TGT
 WHERE SELECTED.TargetID == param.TargetID ;
IF NOT_EMPTY lgd AND NOT_EMPTY d AND NOT_EMPTY tgt
	CREATE OBJECT INSTANCE dasn OF HC_DASN ;
	RELATE tgt TO d ACROSS R8 USING dasn ;
END IF;

以上で、一通りのパターンが出てきました。

クエリー

今度は、概念情報モデルを使って、情報を取り出すクエリーのアクションを描いてみます。
まずは、ある地方担当行政部局で、何人の被検者がいるかを調べるクエリーです。

SELECT ANY lgd FROM INSTANCES OF HC_LGD
 WHERE SELECTED.部局名 == param.部局名 AND SELECTED.所在地 == param.所在地 ;
result = 0 ;
IF NOT_EMPTY lgd
	SELECT MANY tgts RELATED BY lgd->HC_T[R2.'管轄対象']->HC_TGT[R1] ;
	result = CARDINALITY tgts ;
END IF ;
return result ;

HC_LDG つまり”地方担当行政部局”の概念インスタンスの中から該当するものを選択し、そこから概念情報モデルで定義されたリレーションシップをたどって、その”地方担当行政部局”の概念インスタンスの管轄対象の”被検者”を探し、その数を調べて（CARDINALITY）います。

リレーションシップでたどる

つぎは、ある被検者の計測に使われた健診計測機器の数を調べるクエリーです。

SELECT ANY t FROM HC_T
 WHERE SELECTED.管理番号 == param.管理番号 ;
result = 0 ;
IF NOT_EMPTY t
	SELECT MANY mcds RELATED BY t->HC_TGT[R1]->HC_MM[R5.'を行った']->HC_MCD[R7.'で測った'] ;
	result = CARDINALITY mcds ;
END IF ;
return result ;

こちらも、概念情報モデルで定義されたリレーションシップをたどって情報を取得しています。

リレーションシップをたどる

SQL 文に似ている？