【連載】概念モデリングを習得しよう：概念モデルのシミュレーションと状態モデルの実行セマンティクス（第23回）

ドメインファンクションの説明で、アクションはデータフローモデルであり、データフローモデルの実行セマンティクスに従ってプロセスの実行が行われると解説しました。ここでは、状態モデルの実行セマンティクスを、図表を交えて定義しておきます。実行セマンティクスが明確に定義されていれば、誰かが描いた状態モデルが実際どうふるまうのか、誰が試してみても、同じ振舞いになることが保証されるからです。

逆に、明確な実行セマンティクスが無ければ、たとえ同じ状態モデルを対象としていても、人によって解釈が異なってしまい、せっかく苦労して描いた状態モデル群も絵にかいた餅で終わってしまいます。

以下に、生起されたイベントのルールを列記します。

• ある状態機械に対して、異なる状態機械、及び、概念ドメインの埒外が生起したイベントの消費順は不定である
  ▶　二つイベントが生起された場合、どちらのイベントを先に受け取っても妥当な遷移が行われるような状態モデルであること
• ある状態機械が、別の状態機械に対して二つ以上のイベントを生起した場合、消費する側の状態機械は、生起順にイベントが消費される
• ある状態機械が、自分自身に対してイベントを生起した場合、そのイベントが最初に消費される
• 生起されたイベントが状態機械に消費されるまでには有限の時間がかかる

これらは現実の世界の様相をもとに決められたルール群です。例として挙げている果樹園のモデルだけでなく、日常業務における各種やりとり、制御システムにおける連携など想像してみれば、これらのルールの妥当性が腑に落ちることでしょう。

前述の通り、生起されたイベントに対し、ある状態機械の遷移が生じ、遷移先の状態のエントリーアクションが実行されます。その際、そのエントリーアクションを構成する全プロセスは、データフローモデルの実行セマンティクスに従って、それぞれの入力データが揃った時点で同時並行的に実行されていきます。エントリーアクションにひも付く全てのプロセスが実行されて状態の遷移が確定するまでの状態を、中間状態（イミディエイトステート）と呼びます。エントリーアクションを構成する、それぞれのプロセスが同時並行的に実行されるというルールにより、中間状態では、概念情報モデルで記述されたプロパティ値の確定や、リレーションシップの多重度に関する制約が破られてしまう状況がどうしても生じてしまいます。このため、全プロセスの実行が完了した時点、すなわち、状態遷移が確定した時点では、概念情報モデルの制約が満たされていなければなりません。

繰り返しになりますが、現実の世界ではそこかしこで出来事が起こり、同時並行的に物事が進行していきます。現実世界の写しである圏Iでは、複数の状態機械がそれぞれのイベントの生起に応じて動いていることを考慮しモデリングしなければなりません。ある状態機械のエントリーアクションにおいて参照している意味的リンクや概念インスタンスが、別の状態機械のエントリーアクションで削除されているかもしれません。そのような状況を考慮せずに状態モデルを作成していると、全体を俯瞰したときに概念情報モデルによる制約が満たさない状況が生じてしまうかもしれないのです。

現状のビジネスや制御の状況を可視化したものが概念モデルです。次に解説するシミュレーションにより、概念情報モデルで定義された各種制約が満たされないような振舞いを見つける場合があります。これは、何か重要な事実を見落とすことにより、作成したモデルが間違ったか、現状に潜んでいた問題点を発見したかのどちらかです。

こんな時は関係者を集めて、作成したモデルが、意味の場を通じて観察している対象を正しく記述しているかを吟味してください。正しく記述しているにもかかわらず、概念情報モデルの制約が満たされない状況が生じているならば、実際の世界で何らかの論理的破綻が生じる可能性があることを示唆しています。概念情報モデルと状態モデル群を使うことにより、現状の問題が発見でき、モデルを修正しながら、その解決策を探ることができるのです。

状態モデルについては、
“Art of Conceptual Modeling 4. 概念振舞いモデル”
で詳しく解説しています。このコラムも是非ご一読ください。

概念モデリングでは、エントリーアクションも含めた状態モデルとドメインファンクションをまとめて、概念振舞いモデルと呼ぶことにしています。

概念情報モデルを基に、現実世界の写しである圏Iのモデルを構成し、イベントを生起すれば、状態モデルに従った圏Iのモデルの変化が生じます。その変化を観察することにより、現実世界のシミュレーションを行えます。

より厳密に言えば、概念モデルを使って次のような事柄を実行することがシミュレーションに相当します。

• 現実世界に対応する圏Iのモデルを構成する
  ▶　ドメインファンクションによるアクション記述と実行
  　　　▷　存在する概念インスタンスの生成
  　　　▷　概念インスタンスの特徴値の値の設定
  　　　▷　概念インスタンス間の意味的リングの作成
• イベントの生起
  ▶　概念インスタンスを生成するイベントの場合
  　　　▷　状態モデルをひな型として、一つの状態機械を作成する
  　　　▷　生成イベントが紐づいた遷移先の状態のエントリーアクションを実行する
  ▶　既存の概念インスタンスに対するイベントの場合
  　　　▷　その状態機械の現在状態から遷移先の状態を見つける
  　　　▷　遷移先の状態のエントリーアクションを実行する
• 圏Iのモデルを観察する
  ▶　観察したい事項を参照するドメインアクション記述と実行
  　　　▷　概念インスタンスの生成・消滅
  　　　▷　概念インスタンスの特徴値の変化
  　　　▷　意味的リンクの作成・削除

シミュレーションは、概念情報モデル図と全ての状態モデル図、大きめのホワイトボード、マーカー、ポストイットなどを使うことにより、以下の手順で、人手で実践できます。

1. 初期状態で作成する概念インスタンスそれぞれに対し、（ア）～（エ）を行う
   （ア）ポストイットに概念クラスの名前と識別子特徴値の値を書き込んでホワイトボードに張る
   （イ）リレーションシップをひな型にした意味的なリンクを、ポストイットをつなぐ線として書き込み、リレーションシップの名前を付与する
   （ウ）状態モデルが定義されている場合は、そのモデル図のコピーを一枚作成し、識別子特徴値の値を書き込むと共に、初期の状態にマーカーを置く
   （エ）概念クラスの特徴値をカラムとした表（ “概念インスタンス表” ）を作成し、概念インスタンス毎に行を作成して、全ての特徴値の値を書き込む
2. 生起するイベントごとに、（ア）を行う
   （ア）ポストイットに、そのイベントラベルと、消費先の概念インスタンスの識別子特徴値の値と引数の値を書きこみ、ホワイトボードに貼る
3. 張られたポストイット、それぞれに対して、（ア）～（オ）を行う
   （ア）ホワイトボードからはがして、消費する概念インスタンスの状態モデル図のコピーを探し、遷移先の状態を特定し、マーカーをその遷移線に移動する
   （イ）遷移先の状態のエントリーアクションを実行し、
   　　　①ホワイトボード上の概念インスタンスの特徴値・リンクを更新する
   　　　②生成されたイベントを示すポストイットを作成し、ホワイトボードに貼る
   （ウ）更新された特徴値の値で、対応する概念インスタンス表の値を更新する
   （エ）エントリーアクション実行完了時点で、マーカーを遷移先の状態に移動する
   （オ）遷移先の状態が最終状態の場合は、対応する概念インスタンスのポストイットをはがし、それに紐づいた特徴値・リンクを消すと共に、対応する状態モデル図のコピーを破棄する
4. 2.～3.の実施経過を（ア）、（イ）、（ウ）に対して観察・記録する
   （ア）生成されたイベント
   （イ）概念インスタンス表の行、セルの更新履歴
   （ウ）概念情報モデルで定義された制約を満たしているか確認
   　　　①リレーションシップの多重度
   　　　②特徴値の値制約

シミュレーションは複数人で実施するのが良いでしょう。その際、前記した2と3を同時並行で行うことにより、現実世界に忠実なシミュレーションが可能です。

実際やってみると、人手によるシミュレーションは、非常に手間のかかるタフな作業です。

概念モデリングの基である Shlaer-Mellor 法専用ツールの BridgePoint には Model Verifier というツールが用意されています。このツールを用いればシミュレーション実行に伴う苦痛を幾ばくか和らげてくれるでしょう。

繰り返しになりますが、概念モデルは、意味の場を通じて認識した現実世界の写しのスキーマです。それゆえ、概念モデルを使ったシミュレーションでは、その実行中の圏Iのモデルの変化が、現実世界の様相と齟齬がなく、忠実な写しになっていなければなりません。これが、作成した概念モデルが妥当であることを示す唯一の指標だからです。

シミュレーションの実行は、作成したモデルの動的な側面の妥当性を検証（Verify）することと同義であるといえます。BridgePoint で提供されているシミュレーション用のツールの名前が、Model Simulator ではなく、Model Verifier になっていることにはこれに由来しています。

余談になりますが、シミュレーション中の、概念インスタンス間で生じたイベントの、送受信の時系列的な流れの図示は、UML の相互作用図が利用できます。また、その流れの中で実行されたアクションやプロセスの時系列的な関係を図示したい場合は、UML のアクティビティ図を利用するとよいでしょう。なお、これらの様相を図にする際、それらの図は、圏Cをひな型とした 圏Iの世界の描写であることに留意してください。これら圏Iの図は、シミュレーションの条件をちょっとだけ変えるだけで、大きく変化してしまうからです。

モデリングでは、ひな型の圏Cのモデリングに注力し、それから導出可能な圏Iのモデル図は変化しやすいので、作成することは必要最低限にとどめ、無駄な労力をかけないようにしましょう。

次回は、概念モデルのシミュレーションを通じて、リソース競合などのビジネス上の問題をどのように発見し、解決策へつなげていくのかを、果樹園のドメインを題材に解説します。