UML2.0 状態マシン図（ステートマシン図）の完了遷移


今年のETロボコンでは、中四国地区の実行委員も担当させていただき、みなさんのかいたモデルを見せていただく機会が増えました。
以前より状態マシン図をかくチームが増えて、[SESSAMEの状態マシン図設計セミナー](http://www.sessame.jp/seminar/Seminar2017_11/index.htm)のアシスタントをしている身からすると、とても嬉しいことです。
今年一年、みなさんのモデルを見ていて、あれ？もしかして知らない？と思って、中四国地区秋の独自勉強会で取り上げたらやっぱり知らない人が多かったものに「完了遷移」があります。
ググってもあまり出てこないようなので、ここでも紹介しておきます。

# 対象
UML2.x のStateMachine Diagramについてです。
この状態マシン図っぽいものはUMLの図として新たに考え出されたものではなくて、UML以前から存在していました。
なので、ここでは対象を特定するためにUML2.xのStateMacine Diagramという言い方をしています。以降このStateMachine Diagramのことを状態マシン図と呼ぶことにします。[^1]

# 完了遷移(Completion Transitions)とは

状態を起点とするtrigger[^2]の書かれていない遷移のことです。
図でかくとこんな感じ。この遷移（矢印）にはtriggerがなくてもよいのです。
UMLの仕様書を見るとちゃんと書いてあります。
<img width="193" alt="スクリーンショット 2018-12-24 18.32.07.png" src="https://qiita-image-store.s3.amazonaws.com/0/61488/a13d5098-86d6-8f87-5dcb-9475940e4020.png">


## UMLの仕様
というわけで、早速[UMLの仕様書 2.5.1(2018/12/20時点の最新版)](https://www.omg.org/spec/UML/)を確認してみましょう。
リンク先にあるページの中程にあります（下図参照）
<img width="1016" alt="OMG-UML2.5.1.png" src="https://qiita-image-store.s3.amazonaws.com/0/61488/7a577a7e-ce35-5e09-7b71-658162806591.png">

P314の14.2.3.8.3 Completion Transitions and completion events
のところに説明があります。ちょっと訳してみましたが、長くなったので、最後におまけとしてつけておきます。

完了遷移について要約するとこんな感じでしょうか。

```
遷移には完了遷移というのがある。この完了遷移にはtriggerは書かれてないけど、実は暗黙のtriggerがある。
暗黙のtriggerは完了イベントと呼ばれるイベントが契機となる。
この完了イベントは、完了遷移の起点となっている状態に関連づけられた全ての振る舞いの実行が完了したら起きる。
完了遷移にはガードがある場合もある。
```

一言でまとめると、「状態に書かれていることが全て終わったら完了遷移が起きて次の状態にいく」ということですね。
具体例でいうと、「初期化が終わったら、スタートボタン押下待ち状態にいきたい」という場合はこんな感じにかけますね。

<img width="581" alt="スクリーンショット 2018-12-24 18.31.16.png" src="https://qiita-image-store.s3.amazonaws.com/0/61488/a4599578-8928-9e6f-6370-0e0aedba2457.png">

# まとめ
## 遷移について
遷移には「完了遷移」と呼ばれるものがあります。
完了遷移にはtriggerはないですが、ガードはある場合もあります。

## UMLの仕様書を読もう
ここでは完了遷移をUMLの仕様書を使って調べてみました。

### おまけ
14.2.3.8.3 Completion Transitions and completion events
完了遷移と完了イベント

> A special kind of Transition is a completion Transition, which has an implicit trigger. The event that enables this trigger is called a completion event and it signifies that all Behaviors associated with the source State of the completion Transition have completed execution. 

完了遷移は特殊な遷移で、暗黙のtriggerを持っています。
このtriggerを可能にするイベントは完了イベントと呼ばれて、完了遷移のsource[^3]となる状態に関連づけられたすべての振る舞いが実行完了したことを示します。

> In case of simple States, a completion event is generated when the associated entry and doActivity Behaviors have completed executing. If no such Behaviors are defined, the completion event is generated upon entry into the State. For composite or submachine States, a completion event is generated under the following circumstances:
・ All internal activities (e.g., entry and doActivity Behaviors) have completed execution, and
・ if the State is a composite State, all its orthogonal Regions have reached a FinalState, or
・ if the State is a submachine State, the submachine StateMachine execution has reached a FinalState.

単純状態の場合、関連するentryとdoアクティビティ[^4]の振る舞いの実行が完了したとき、完了イベントが生成されます。
そのような振る舞いが定義されていなかったら、完了イベントはその状態のentryで生成されます。
コンポジットまたはサブマシン状態の場合、完了イベントは以下のように生成されます。

- 全ての内部のアクティビティ（例えば、entryやdoアクティビティ）の実行が完了していて、
- その状態が複合状態の場合、すべての直交する領域が最終状態に到達している、または、
- その状態がサブマシン状態の場合、そのサブマシンの状態マシンの実行が最終状態に到達している

> Completion events have dispatching priority. That is, they are dispatched ahead of any pending Event occurrences in the event pool. If two or more completion events corresponding to multiple orthogonal Regions occur simultaneously (i.e., as a result of the same Event occurrence), the order in which such completion occurrences are processed is not defined.
Completion of all top level Regions in a StateMachine corresponds to a completion of the Behavior of the StateMachine and results in its termination.


完了イベントはディスパッチする優先度を持っている。
つまり、完了イベントはイベントプールにあるすべてのペンディング中イベントの発生前にディスパッチされる。
複数の直交する領域に該当する２つ以上の完了イベントが同時に起きる場合（すなわち、同じイベントの発生の結果として）そのような完了の発生が処理される順序は定義されない。
状態マシンのすべての最上位の領域の完了はその状態マシンの振る舞いの完了に一致し、終了となる。

> Transition guards
>
> A Transition may have an associated guard Constraint. Transitions that have a guard which evaluates to false are disabled. Guards are evaluated before the compound transition that contains them is enabled, unless they are on Transitions that originate from a choice Pseudostate. In the latter case, the guards are evaluated when the choice point is reached. A Transition that does not have an associated guard is treated as if it has a guard that is always true.

（遷移についている）ガード（条件）
遷移は関連するガード制約を持つことができる。falseに評価されるガードを持つ遷移は無効になる。
遷移のガードが選択擬似状態を起源としなければ、ガードはそれらを含む複合遷移が有効になる前に評価される。
選択擬似状態の場合、選択擬似状態に達するとガードが評価される。
関連するガードを持たない遷移は、常に真のガードを持っているかのように扱われる。

> NOTE. A completion Transition may also have a guard.

注意：完了遷移はガードがある場合もある

> A guard constraint may involve tests of orthogonal States of the current StateMachine, or explicitly designated States of some reachable object (for example, “in State1” or “not in State2”). State names may be fully qualified by the nested States and Regions that contain them, yielding pathnames of the form “RegionA::State1::Region1::State2::State3”. This may be used in case the same State name occurs in different composite State Regions.

ガード制約はカレントの状態マシンの直交の状態もしくは、または明確に指定された到達可能な状態(例えば、「状態1」や「状態2でない」)のテストにかかわる。
状態名は入れ子になった（ネストされた）状態とそれらを含む領域によって完全に修飾され、「RegionA::State1::Region1::State2::State3」形式のパス名を生成する。
これは、同じ状態名が異なるコンポジット状態の領域にある場合に使われる。


[^1]: あえて英語表記をしたのは対象を特定するためで、状態マシン図の他にステートマシン図という呼び名がよく使われているようです

[^2]: 日本語ではトリガー、トリガ、イベントなどと呼ばれているようです。

[^3]: ソース、ターゲットのソースですね。完了遷移の起点となっている状態のことです。

[^4]: ソースとなる状態のenter/doActivityのことですね