【連載】概念モデリングを習得しよう：状態モデルで世界の変化を記述する、イベントと状態の整理法（第20回）

さて、状態モデルを記述するためには、イベントと状態を抽出しなければなりません。

どのような事柄・状況を、イベント・状態とするかは、モデル化対象の概念ドメインの振舞いをどのように、そしてモデル作成者がどのように認識するかで決まります。

このことを説明するために、果樹園のモデルにいくつかの概念を追加することにします。

人間は神様ではないので、最初から意味の場に存在する全ての概念を拾い上げることはできません。しょせん見たいものだけしか見えないのが人間です。そういう観点からすると概念情報モデルは、常に不完全と言えるかもしれません。新しい発見があれば躊躇なく概念情報モデルを変更していきましょう（図表1）。

以前に例示した果樹園の概念情報モデルの一部を切り出して、これまであまり明白には記述していなかった、リンゴの収穫に関する事柄の概念を追加しました。

樹木からのリンゴの収穫には、それを行うためのリソース（資源）が必要です。最近では、https://smartagri-jp.com/smartagri/2416 にあるような収穫を自動化するロボットも開発されているようですが、少なくとも、収穫作業を行う作業者の人手や収穫したリンゴを収納するカゴやハサミなどの備品類は必要でしょう。

例示したモデルは、その詳細には立ち入らず収穫作業を行うために必要なリソース（資源）としてまとめて“収穫リソース{PHR}”と言う概念クラスを定義しています。

一日かけてそれぞれの“収穫リソース”を使って、一本の“樹木”のリンゴ全てを収穫することを想定しています。

それぞれの“収穫作業”が、“収穫{PH}”という概念クラスの概念インスタンスであるとしています。さらには、樹木の収穫予定日が確定すれば、その予定日には、収穫のための“収穫リソース”が一つ必要になり、リソースの予約が必要になるので、それを“収穫予約{PR}”として定義しています。

まずイベントについて例を挙げながら説明していくことにします（図表2）。

栽培中のリンゴと樹木の状態モデル 樹木の状態モデルには、収穫予約を生成するイベントが生起するのと、収穫予約確定というイベントを受信することを描く（収穫予約確定は引数として収穫予定日が伴われる。なぜなら競合するから）

リンゴが生る、樹木の収穫予定日の確定などは、自然の摂理に従って生じる出来事です。このような出来事は、イベントの候補となります。

実際には、目視や画像AIなどの具体的な手段で、リンゴがなったこと、それらのリンゴが熟して収穫の期が予測できたことの把握が必要です。

それら手段は時々の必要条件を満たせば何でもよいというのが、筆者の認識だと考えてください。何でもよいので、現在モデルを描いている“果樹園”という意味の場では、あえて取り上げないという表明でもあると考えてください。

概念モデリングを実践する際、このような割り切りをするのがコツの一つです。もちろん、作成しているモデルを基にシステムを構築する際には、何らかの手段を特定・選択しなければなりません。その手段は、“果樹園”とは別の意味の場として扱いながら、システム構築時に検討すれば十分です。

状態にひも付いたエントリアクションは、Domain Function の解説で紹介した OAL（Object Action Language）を使って記述しています。

SELF というキーワードが使われています。SELF は、状態モデルをひな型にした状態機械がひも付く概念インスタンスを指します。

SELF.特徴値名

により、SELF が指す概念インスタンスの特徴値の値にアクセスします。

他に、樹木の“状態名”に、収穫予約への生成イベントを生起する、次のアクションが記述されています。

GENERATE PR1:予約要求(樹木ID:SELF.樹木ID) TO PR CREATOR ;

これは、樹木の“2. 収穫作業確定待ち”という状態に遷移した際のエントリアクションで、“収穫予約”に対する生成イベントを生起する”ことを意味します。

このアクションは、ドメインファンクションの説明で紹介した、次の“収穫予約”の概念インスタンスを一つ作成するというプロセスでも記述が可能です。

CREATE OBJECT INSTANCE pr OF PR ;

しかし、モデル作成者である筆者の認識・判断として、あえて、イベントとして定義するという選択をしています。

この例では、概念インスタンスを一つ作成する生成イベントの生起を紹介しましたが、図表3の“状態名”のように、ある概念インスタンスに対するイベントを、自身に対するイベントも含め、生起が可能です。

 GENERATE TR… TO tree ;

このように、イベントは、概念ドメインの埒外から生起されるものと、概念インスタンスにひも付いた状態機械のアクション実行中に生起されるものの二種類が存在します。

ただし、生起されたイベントを消費する側では、そのイベントがどこで生起されたのかについて、一切の仮定を置くことは許されていません。

現実の世界においても、ある出来事がなぜ生じたのか勝手に判断するのには危険が伴います。

状態機械は自身に対して生起されたイベントを、そのイベントが誰によって生起されたかにかかわりなく、粛々と消費して状態を遷移する、これが、概念モデリングのルールです。

モデル化対象の意味の場の中には、時間の経過と共に変化が生じる世界があります。

概念モデリングでは、時間の経過も出来事の生起と捉え、状態モデル上で次のイベントとして記述します（図表4）。

• 一定の時間が経過した
• ある日時になった

一見、連続的に流れているように見える時間の経過を、出来事として捉えるのは奇妙に思われるかもしれません。しかし、概念モデリングが記述するのは、意味の場を通じて観察している世界の意味の構造を記述する概念情報モデル（圏Cのモデル）です。

概念情報モデルを物差しに、観察者は、時点々々で、世界の状態を圏Iのモデルとして認識します。時点々々の圏Iのモデルは、それぞれの時点でのスナップショットに過ぎません（図表5）。

ある時点から次の時点で圏Iのモデルに変化があるとすれば、その変化を引き起こす何らかのイベントが生起していることになります。時間の経過によって圏Iのモデルに変化があるならば、イベントとして捉えることに、論理的な矛盾はないでしょう。

数学においては、物事の変化は微分積分で扱われる領域です。ある範囲を分割して値の差を、分割の幅を小さくしながら計算していく、それが、工学的に実用上問題のない範囲での微分積分の定義です（図表6）。

概念モデリングにおける時間の取り扱いは、この定義とも矛盾してはいません。リアルタイム制御システム開発においては、実時間制約を満たすことが重要ですが、この分野においても、概念モデリングは、開発対象の理解・記述方法として利用可能です。

概念モデリングの基になっている Shlaer-Mellor 法には、F16 戦闘機のクルーズコントロールやサンフランシスコの鉄道運行制御、加速器のシンチレーション検出器など、実時間制約が厳しいシステムでの開発の実例があります。

連続性には、次の二つがあります。

• 自然数無限による連続性

  ▶ 1、2、3と無限に続く

• 実数無限による連続性

  ▶ 隙間なく無限に連なっている

この説明に引っかかっている読者がいるとすれば、時間の連続性が後者であると思っているからかもしれません。

極微の世界を扱う量子力学や場の量子論においては、プランク定数より小さい領域での時間の連続性が、どちらなのかはいまだに不明です。そんな状況を踏まえれば、概念モデリングによる時間の扱い方は、実用上問題ないでしょう。
そこまで、気にする人はそうそういないでしょうが、念のため言及しました。

時間の経過をイベントとして捉えるということは、さまざまな場所に点在する概念インスタンスにひも付く状態機械が、そのイベントを、局所的に消費するということと同義です。

これは、概念モデリングにおける時間の取り扱いが、ニュートン力学のような絶対時間・絶対空間的な考え方ではなく、アインシュタインの相対論的な局所的な時間・空間と同様な扱いであることを意味します。

ニュートンやアインシュタインという大仰な話（苦笑）を持ち出すまでもないのですが、あなたが時間を確認したい時、手近にある時計を見ますよね。機器に設置されたセンサーで値を計測するとしても、計測した時間は機器に備わったリアルタイムクロックで測るでしょう。それぞれの場所にある時計やリアルタイムクロックが全て同じ時を示している保証はどこにもありません。

GPS や NTP Server による時間合わせをしていたとしても、物理的に離れたノード間の通信にはある程度の時間がかかるので、厳密に同一の時間を示すことはあり得ませんし、同じであることを確かめる術もありません。リアルタイム制御システムの実時間制限の取り扱いだけでなく、インターネットでつながったエンタープライズな IT システムにおいても、遅延を考慮することは重要です。概念モデリングの状態変化の記述においては、そのような要件も自然な形での表現が可能です。

以上、一見すると時間経過による連続的な変化があるようなモデル化対象に対しても、

時間経過＝イベント

という取り扱いは、実用上問題がないことを見てきました。安心してこの考え方を、あなたの問題解決で採用してください。

ここまで読んできて、時間の経過も含め、イベントが生成される仕組みや、生起されたイベントが概念インスタンスに届く仕組みが気になってしょうがない、通常のプログラミングに慣れた技術者が多数いるのではないでしょうか。

概念モデリングにおける状態のモデル化では、そのような仕組みを考える必要は一切ありません。
モデル化対象の現実世界で、“どんな仕組みで”ではなく、“何が起こっているか”を、意味の場を通じて拾い上げることに注力するのが、状態のモデル作成時の要諦です。

そもそも、この物理世界がどのように成り立っているのか、正確に理解している人なんて、この世には存在していません。それらの仕組みを考えるのは、作成されたモデルをもとにシステムを組み上げるフェーズになってからで十分です。具体的にどうするのかは、概念モデリングで作成する全てのモデルの解説が終わったあと、詳しく解説する予定ですので、楽しみに待っていてください。

次回は、概念モデリングにおける「状態」とは何か、そして状態モデルをどのように導出・整理するのかについて、エントリアクションとの関係やUMLとの対応も含めて解説します。