【連載】概念モデリングを習得しよう：圏Iの更新を「イベント」と「状態遷移」で読み解く、概念クラス別の状態モデル設計（第19回）

世界は刻一刻と変化していきます。世界が変化するということは、われわれが意味の場を通じて記述した圏I のモデルが、それに応じて変化することを意味します。圏Iのモデルが変化するということは、以下のようなことが生じることと同義です。

• 概念インスタンスの特徴値の、値の変化
• 概念インスタンスの生成・消滅
• 概念インスタンス間の意味的なリンクの生成・消滅

変化は何らかの出来事の生起によって起こります。出来事が生起しなければ、圏Iのモデル（＝モデル化対象の世界）には、未来永劫、何らの変化も生じません。
出来事は、対象世界のさまざまな場所で発生します。人間の認識においては、概念インスタンスや特徴値、意味的リンクと同様、それぞれの出来事の生起を区別します。

この“出来事”を、概念モデリングでは、“イベント（Event）”と呼びます。イベントは、概念インスタンスと同様に、その性質を記述する特徴値を伴う場合があります。その特徴値のことを“イベント引数”と記すことにします。
ただ単に“イベント”と書くと、分類としてのイベントと、それぞれの時々で生起するイベントのどちらのことを指しているのか分かりにくくなります。

そこで明確に示したい場合は、それぞれの区別されたイベントのことを、アンダーライン付きの斜体文字で“イベントインスタンス”と記すことにします。
概念モデリングにおいては、それぞれのイベントインスタンスは、それが生起した時点に、次のどちらかであるとします。

• 概念インスタンスが一つ生成される
• 存在しているどれか一つの概念インスタンスによって消費される

果樹園という概念ドメインにおいて、リンゴを考えてみます（図表１）。栽培中の樹木には、ある時点でリンゴが生るでしょう。この時、“生る”というイベントが生起し、それに伴ってリンゴが一つ生成されると記述するものとします。
これが前者の例です。この場合、概念情報モデルの定義を満たすために、以下のようなアクションが同時になされなければなりません。

• 栽培中のリンゴが一つ生成される
• それに対応するリンゴを一つ生成しR1でリンクを張る
• 引数が示す樹木とR2のリンクを張る

次に樹木を考えてみます。
何らかの基準を基にある時点で、収穫予定日が確定するものとしましょう。これを“予定日確定”というイベントが生起して、その樹木が消費すると記述するものとします。これが後者の例です。この場合、イベントを消費した樹木の収穫予定日が、イベント引数の日時に更新されることになります。

果樹園という概念ドメインにおける例を二つ挙げてみました。
イベントの生起によって状態が遷移するような様相は、状態遷移図（State Transfer Diagram）を使って記述するのが一般的です。状態遷移図は、複数の状態とイベント、イベント生起による状態間の遷移で記述します（図表2）。

状態遷移図で描かれた状態変化の内容のことを状態モデル（State Model）と呼ぶことにします。図は、UML表記に従っていますが、内容が同じであれば別の形式の図でもテキストによる表記でも構いません。

圏Iのモデルは、その時々に意味の場を通じて観察した現実世界のスナップショットです（図表3）。各時点におけるモデル化対象の世界の状態は、圏Iのモデル全体で記述されるのが基本です。そうであれば、出来事の生起による状態変化の記述は、圏Iのモデル全体が関与するものであるべきでしょう。その考え方に基づけば、意味の場（概念ドメイン）に対して一つの状態モデルを作成するのが良いように思えるかもしれません。

しかし、先程の例でも紹介したように、それぞれのイベントインスタンスは、さまざまな場所で、同時並行的に生起します。生起の起こり方は千差万別であり、かつ、それぞれのイベントインスタンスの生起に対する圏Iのモデルの変化は局所的です。

UMLによる表記では、階層化も含む複雑な状態遷移図を描く記法が用意されています。そういった記法を駆使して、頑張って1枚の状態遷移図でモデル化し、図として表記することも可能です。しかし、それはとても複雑な図になるでしょう。さらには、実際のモデル化対象の世界はシンプルではありません。そんな状況では、出来上がった状態遷移図の正しさを検証できるはずもありません。つまりは、圏Iのモデル全体を対象にした状態遷移図を記述するのは困難だということです。

一方で、前の例でも説明した通り、イベントの生起に伴う変化は、局所的です。状態変化の様相は概念インスタンスの振る舞いとしてモデル化する方が、見通しの良い明快なモデル図になります。
それ故、概念モデリングでは、概念インスタンスの状態は次の二つの動きをします。

• 概念インスタンスがイベントを消費する際に、新しい状態に遷移する
• 遷移の際、圏Iの状態の変化が生じる

概念インスタンスの状態遷移図は、意味の場を通じて観察している現実世界に生起する、さまざまな出来事をイベントとして拾い上げ、以下を表現するための状態モデルを作っていきます。

• それらイベントがひも付く概念インスタンスを決める
• イベントを消費する概念インスタンスの状態と遷移を定義する
• 遷移の際に生じる状態変化を明らかにする

概念インスタンスは、ひも付けられたイベントインスタンスの生起のたびに、図に定義された状態遷移に従って状態を変えていくことになるわけです。
結果として、時点ごとの概念インスタンス群の状態の集合が、圏Iのモデル全体の状態を記述することになります。

それぞれの概念インスタンスに注目すると、生起されたイベントインスタンスがどれか一つの概念インスタンスにひも付いて遷移を起こし、それに伴う状態変化を起こす処理（アクション）が実行された後、状態遷移が確定するという流れになっています。

UMLの用語を借りれば、その処理（アクション）は、エントリアクション（Entry Action）であると言えます。UMLの状態遷移図では、Transition（遷移中）、Do（状態にいる間中）、Exit（状態を出る時）アクション（Action）など多彩な記法が存在しますが、概念モデリングで使う状態遷移図は、Entry Action だけを用います。階層化も行いません。

概念インスタンスの状態遷移図は、この道具立てで十分です。これまで述べてきた通り、意味の場を通じた現実世界の写しとする概念モデリングにおいては自然な認識・記述であり、筆者のこれまでの経験からも、足りないということはありません。

ここで、圏Iのモデルで記述された、概念インスタンスとその特徴値、意味的なリンクは、圏Iの意味的な構造（スキーマ）を記述した概念情報モデル（圏C）をひな型としていると解説してきたことを思い出してください。そして、概念情報モデルは、圏Iのモデルの構成要素群を分類して、意味の場の概念の意味構造を記述したものであったことも思い出してください。

この考え方を、圏Iの概念インスタンスの状態遷移図群に対しても適用します。
同じ概念をひな型としているなら、同じ状態遷移図を共有するだろうということです。逆から見ると、同じ特徴値のセットとリレーションシップを持ち、かつ、同じ状態遷移図を持つなら、その概念クラスをひな型とする概念インスタンスである、とも言えるでしょう。
この作業を行うことにより、それぞれの概念クラスに対して、以下のことを記述する状態遷移図が出来上がります。

• 状態
• イベント
• 状態遷移
• 遷移の際に生じる状態変化

この状態遷移図で記述された内容が、概念クラスをひな型とする全ての概念インスタンスの振る舞いを規定する“状態モデル（State Model）”です。
概念ドメインにおける全ての概念インスタンスの意味は、概念クラスで定義されています。同じ概念クラスをひな型とした全ての概念インスタンスの状態変化が、概念クラスの状態モデルに従うのは、ある意味、当然と言えるでしょう。

概念クラスの状態モデルで規定された、個々の概念インスタンスの状態遷移の様を状態機械（State Machine）と呼びます。概念クラスが状態モデルを持つ場合、それをひな型とする概念インスタンスは、その状態モデルで規定される状態機械を一つ持つとも言えます。また、状態機械を持つ概念インスタンスは、どれか一つの状態にあるものとします（図表4）。

“遷移の際に生じる状態変化”は、第18回で解説したデータフローモデルを基本とするアクション記述と同じ道具立てを使って記述します。
現実世界では、さまざまな場所での出来事の生起をきっかけにした局所的な状態の更新が行われます。その様相を状態遷移の際の状態変化の操作として記述する方法としては、データフロー的な操作の組み合わせによる記述がふさわしいでしょう。

概念モデリングでは、状態遷移は、状態にひも付けられたアクションの実行が全て完了した時点で遷移が確定するものとします。その時点で概念インスタンスが新しい状態になるわけです。遷移確定時には、概念情報モデルで定義された特徴値の確定や、リレーションシップの多重度が全て満たされなければなりません（図表5）。

しかし、アクション実行中においては、概念インスタンスの生成やリンクの接続、特徴値の確定などのプロセスは、データフローモデルの実行セマンティクスに従って、個別に並行で実行されるため、リレーションシップの多重度などの制約を満たさないタイミングが存在することになります。
このためアクション実行中には、概念情報モデルで定義されたリレーションシップの多重度や特徴値の制約が破れていても構いません。

概念クラスの状態モデルの記述方法を、図表6と共に示します。

• 状態

  　▶番号と名前を付与

• イベント

  　▶概念クラスの短縮名（名前右横の{}でくくられた数文字のアルファベット表記）＋番号で表すイベントラベルと、意味を要約した名前を付与

  　▶加えて、引数（データ型）を明記

• アクション

  　▶それぞれの状態にエントリアクションとして記述

• 遷移

  　▶その遷移を引き起こすイベントを明記

  　▶ある状態への遷移を引き起こすイベント引数のシグネチャは、全て同じであること

• その他

  　▶●からある状態への遷移は、その遷移にひも付いたイベントが生起したときに概念インスタンスが一つ作成されることを意味し、そのイベントを“生成イベント（Creation Event）”と呼ぶ

  　▶中の円が黒い◎への遷移がある状態は、その状態のアクションの実行完了後に、状態機械が削除されることを示し、その状態を“最終状態（Final State）”と呼ぶ

図表6には、モデル記述言語の標準である UMLによる表記を参考までに描いています。概念モデリングの状態モデルで記述する、状態にひも付けられたアクションは、UML風には状態のエントリアクションであると言えます。
繰り返しになりますが、UMLのステートモデル表記では、アクションをひも付ける場所がエントリだけでなく、遷移やエグジットなども想定され、さらに状態の階層化など非常に複雑な状態モデルが描けるようになっています。

こういう派手な道具立てを目にすると、全ての道具を使って複雑な状態モデルを描こうという気持ちになってしまいがちです。しかし、複数の事柄が同時並行的に移り変わっていくような状況をモデル化することは、一般的なプログラミング言語のような上から順番に実行されていくようなモデルに比べて、格段に難しいものです。

モデルは記述すればそれでおしまいということではなく、その記述の正しさの検証が必要だからです。検証が難しければ、間違いを見逃しやすくなってしまいます。ただでさえ複雑で難しい状態を持った状況のモデルの扱いには、概念モデリングで採用しているようなシンプルな状態モデルで表現することをお勧めします。

筆者の個人的な感想ですが、一見すると階層化といった複雑な記法が必要と思われるのは、大抵の場合、圏I全体の状況を対象にしているように思えます。
概念情報モデルを作り、概念クラスごとに状態モデルを記述すれば、階層化など必要ないフラットな状態モデルになるものです。概念モデリングに限らず、何かをモデル化するときには、自分が今対象としているのは、圏Iなのか、そのスキーマの圏Cなのかを意識することが大事です。

次回は、概念モデリングにおける「状態」とは何か、そして状態モデルをどのように導出・整理するのかについて解説します。