2021年8月31日火曜日

Kaleidox:状態機械/リソース

前回は状態機械のヒストリー機能を用いて保留機能をモデル定義し、Kaleidox上で動作させました。

ここまで取り扱ってきた状態機械は、ローバルなスコープとなっていて、発生した該当イベントの全てに反応するものでした。

システム上に状態機械が1つしかない応用の場合はこれでよいですが、システムのリソースごとに状態機械を持ちたい場合には、ターゲットのリソースに対応付けられた状態機械のみ反応するための仕掛けが必要です。

今回はリソースに対応した状態機械を定義してKaleidox上で動作させてみます。

モデル

今回のモデルは前回のモデルに対して以下の拡張を行っています。

  • 状態機械purchaseの種別をresourceにする

具体的には以下の設定を入れます。

  1. statemachine={  
  2.   name="purchase"  
  3.   kind=resource ← この設定  

この設定を行うことで、定義した状態機械はリソースに関連付けられます。

この設定を行った状態機械の定義は以下になります。

  1. * event  
  2. event=[{  
  3.     name="confirm"  
  4.   },{  
  5.     name="reject"  
  6.   },{  
  7.     name="delivered"  
  8.   },{  
  9.     name="cancel"  
  10.   },{  
  11.     name="suspend"  
  12.   },{  
  13.     name="resume"  
  14. }]  
  15. * statemachine  
  16. statemachine={  
  17.   name="purchase"  
  18.   kind=resource  
  19.   state=[{  
  20.     name=INIT  
  21.     transition=[{  
  22.       to=running  
  23.     }]  
  24.   },{  
  25.     name=canceled  
  26.     transition=[{  
  27.       to=FINAL  
  28.     }]  
  29.   },{  
  30.     name=suspended  
  31.     transition=[{  
  32.       guard=resume  
  33.       to=HISTORY  
  34.     }]  
  35.   }]  
  36.   statemachine=[{  
  37.     name="running"  
  38.     state=[{  
  39.       name=applying  
  40.       transition=[{  
  41.         to=confirming  
  42.       }]  
  43.     },{  
  44.       name=confirming  
  45.       transition=[{  
  46.         guard=confirm  
  47.         to=confirmed  
  48.       },{  
  49.         guard=reject  
  50.         to=rejected  
  51.       }]  
  52.     },{  
  53.       name=confirmed  
  54.       transition=[{  
  55.         to=delivering  
  56.       }]  
  57.     },{  
  58.       name=rejected  
  59.       transition=[{  
  60.         to=FINAL  
  61.       }]  
  62.     },{  
  63.      name=delivering  
  64.       transition=[{  
  65.         guard=delivered  
  66.         to=delivered  
  67.       }]  
  68.     },{  
  69.       name=delivered  
  70.       transition=[{  
  71.         to=FINAL  
  72.       }]  
  73.     }]  
  74.     transition=[{  
  75.       guard=cancel  
  76.       to=canceled  
  77.     },{  
  78.       guard=suspend  
  79.       to=suspended  
  80.     }]  
  81.   }]  
  82. }  

イベント

以下の6つのイベントを定義しています。

confirm
確認OK
reject
確認却下
delivered
配送済み
cancel
キャンセル
suspend
保留
resume
再開

前回からの変更点はありません。

状態機械

定義したモデルの状態機械図は前回と同じ以下となります。

実行

それでは実行してみましょう。

最初にstatemachine-new関数で状態機械を作成します。第1引数には状態機械名を指定しますが、第2引数にリソースを特定するIDとして「12345」を指定しています。

  1. kaleidox> setq sm (statemachine-new 'purchase "12345")  
  2. StateMachine[purchase.running.confirming]  

状態機械purchaseが作成され、confirming状態になりました。

ここでevent-issue関数でconfirmイベントを送出します。

前回までの状態機械はconfirmイベントに反応して状態がdeliveringに変わりましたが、今回の状態機械は無反応です。

  1. kaleidox> event-issue 'confirm  
  2. Event[confirm]  
  3. kaleidox> sm  
  4. StateMachine[purchase.running.confirming]  

リソースに関連付けられた状態機械へのイベント送出にはevent-call関数を用います。第1引数にイベント名、第2引数にイベント送信先のリソースID「12340」を指定しました。

この場合は、先ほど作成した状態機械には変化がありません。

  1. kaleidox> event-call 'confirm "12340"  
  2. Event[confirm]  
  3. kaleidox> sm  
  4. StateMachine[purchase.running.confirming]  

次に第1引数にイベント名、第2引数にイベント送信先のリソースID「12345」を指定しました。

リソースID「12345」は先程作成した状態機械に関連付けられたものです。

今回の場合は、状態機械の状態が無事confirmingからdeliveringに変わりました。

  1. kaleidox> event-call 'confirm "12345"  
  2. Event[confirm]  
  3. kaleidox> sm  
  4. StateMachine[purchase.running.delivering]  

まとめ

今回はリソースに紐付いた状態機械を作成し、リソースIDを使って駆動する状態機械を選択を行ってみました。

次回はエンティティに状態機械に組み込む予定です。

諸元

Kaleidox
0.3.1

0 件のコメント:

コメントを投稿