はじめに

今回も前回に引き続き動的構造を取り上げます。前回は動的構造の中心的な概念のひとつであるイベントとは何かについて説明していきました。これで動的構造については、状態とイベントの2つの概念を説明したことになりますが、今回はこの組合せである、状態遷移について触れていきたいと思います。

状態遷移とは

前々回、状態とは「対象のライフサイクルの中で他の時間帯と異なる特徴を持つ区間である」といった説明をしました。状態遷移とは、この状態がある状態から状態に切り替わることを指します。

図1モータの状態遷移
図1 モータの状態遷移

例えば、図 1はある時間軸の中で、モータの状態が静止→作動→静止と遷移していることを表します。これをUMLのステートマシン図の表記で表すと、図 2のようになります。

図2図1の状態遷移をモデル化
図2 図1の状態遷移をモデル化

この図はモータの状態遷移の一部を取り出したものですが、実際にはモータの取り得る状態遷移には、作動状態から故障状態への遷移のように、多くの可能性が存在します。こうした、対象の取り得るすべての状態遷移の可能性をモデル化したものが動的構造のモデリングと呼ばれるものになります。

もう一度図 1の状態遷移に戻りましょう。図 1ではモータの状態がt1, t2のタイミングで遷移しています。この遷移は何をきっかけにして起こるのでしょうか?こうした状態の遷移は対象内部の変化によって起きることもありますが、多くの場合は対象外部からの刺激によって変化します。この刺激が前回取り上げた、「イベント」になります。
例えば、図 1のt1の遷移を起こすきっかけがスイッチオンのイベント、t2の遷移を起こすきっかけがスイッチオフのイベントだとしたとき、これをUMLのステートマシン図で表すと、図 3のようになります。ちなみに、イベントを伴わない状態遷移の場合、ステートマシン図では遷移の部分にイベント名を書きません。こうした状態遷移のことを自動遷移(ラムダ遷移)と呼びます。

図3 イベントを含めた状態遷移のモデル化
図3 イベントを含めた状態遷移のモデル化

これまでの話をまとめると、動的構造をモデリングするとは、対象がライフサイクル全体を通して取り得る全ての状態遷移の可能性と、その遷移がどのようなきっかけ(イベントの発生)で起こるのかをモデリングすることといえます。
ここで、これまでに状態遷移をモデル化したことがあるという方(UMLでなくてもいいです)は、自分の作ったモデルを思い出してみてください。そのモデルは上記のような考え方で書かれているでしょうか?
経験上、ステートマシン図等の状態遷移のモデルをレビューしていると、上記のような考え方になっていないものをよく見かけます。では、どうなっているのかというと処理の順番をモデル化しているものが多いのです。端的に言うと、状態遷移といいつつ、フローチャートになってしまっていることが多いのです。
前々回~今回までを読んで頂ければ、状態遷移とフローチャートは異なることが分かると思います。特に、何らかの処理を実行すること(フローチャートやアクティビティ図でひとつのアイコンとして示されるもの)と状態(ステートマシン図でひとつのアイコンとして示されるもの)はモデル上の見た目は似てますが、考え方は違うものです。ここで、見た目に惑わされて、処理と状態を同じもののように考えてしまうと、動的構造のモデリングができなくなってしまうのです。
この辺の処理と状態を動的構造の上でどう扱うのかもモデリングする上で大きなポイントになります。次回はこの話を取り上げていきたいと思います。