UML ステートマシン

UMLステートマシン^[1]は、以前はUMLステートチャート と呼ばれていましたが、統一モデリング言語（UML）表記法で表現されるコンピュータサイエンスアプリケーションにおける有限オートマトンの数学的概念の拡張です。

その背後にある概念は、デバイス、コンピュータ プログラム、またはその他の (多くの場合は技術的な) プロセスの動作方法を整理し、エンティティまたはその各サブエンティティが常に複数の可能な状態のうちの 1 つだけにあり、これらの状態間には明確に定義された条件付き遷移があるようにすることです。

UMLステートマシンは、 Harelステートチャート^[2]のオブジェクトベースの変種であり、 UMLによって適応および拡張されました。^{[1] [3]} UMLステートマシンの目標は、従来の有限ステートマシンの主な利点を維持しながら、主な制限を克服することです。UMLステートチャートは、アクションの概念を拡張しながら、階層的にネストされた状態と直交領域という新しい概念を導入します。UMLステートマシンは、MealyマシンとMooreマシンの両方の特性を備えています。これらは、Mealyマシンのようにシステムの状態とトリガーイベントの両方に依存するアクションと、Mooreマシンのように遷移ではなく状態に関連付けられたエントリアクションとエグジットアクションをサポートします。^[4]

「UML ステート マシン」という用語は、動作ステート マシンとプロトコル ステート マシンの 2 種類のステート マシンを指します。動作ステート マシンは、個々のエンティティ (クラス インスタンスなど)、サブシステム、パッケージ、またはシステム全体の動作をモデル化するために使用できます。プロトコル ステート マシンは、使用プロトコルを表現するために使用され、分類子、インターフェイス、およびポートの正当な使用シナリオを指定するために使用できます。

多くのソフトウェア システムはイベント駆動型です。つまり、マウスのクリック、ボタンの押下、タイム ティック、データ パケットの到着など、外部または内部のイベントの発生を継続的に待機します。イベントを認識すると、このようなシステムは適切な計算を実行して反応します。これには、ハードウェアの操作や、他の内部ソフトウェア コンポーネントをトリガーする「ソフト」イベントの生成などが含まれる場合があります。(イベント駆動型システムは、リアクティブ システムとも呼ばれる理由です。) イベント処理が完了すると、システムは次のイベントを待機する状態に戻ります。

イベントに対する応答は、通常、イベントの種類とシステムの内部状態の両方に依存し、状態遷移につながる状態の変化が含まれる場合があります。イベント、状態、およびそれらの状態間の状態遷移のパターンは、抽象化して有限状態マシン(FSM) として表現できます。

FSM の概念は、イベント ドリブン プログラミングにおいて重要です。イベント処理がイベントの種類とシステムの状態の両方に明示的に依存するようになるからです。ステート マシンを正しく使用すると、コードの実行パスの数を大幅に削減し、各分岐点でテストされる条件を簡素化し、異なる実行モード間の切り替えを簡素化できます。^[5] 逆に、基礎となる FSM モデルなしでイベント ドリブン プログラミングを使用すると、エラーが発生しやすく、拡張が難しく、過度に複雑なアプリケーション コードが作成されることがあります。^[6]

UML は、従来の状態図の一般的な形式を維持しています。UML 状態図は、ノードが状態を示し、コネクタが状態遷移を示す有向グラフです。たとえば、図 1 は、コンピューターのキーボードの状態マシンに対応する UML 状態図を示しています。UML では、状態は状態名でラベル付けされた角丸の四角形で表されます。矢印で表された遷移には、トリガー イベントのラベルが付けられ、オプションで実行されたアクションのリストが続きます。最初の遷移は実線の円から始まり、システムが最初に開始するときのデフォルトの状態を指定します。すべての状態図にはこのような遷移が必要ですが、イベントによってトリガーされないため、ラベル付けすべきではありません。最初の遷移には、関連付けられたアクションを含めることができます。

イベントとは、システムに影響を与える出来事のことです。厳密に言えば、UML 仕様^[1]では、 イベントという用語は、その出来事の具体的なインスタンスではなく、出来事の種類を指します。たとえば、キーストロークはキーボードのイベントですが、キーを押すたびにイベントではなく、キーストローク イベントの具体的なインスタンスになります。キーボードの重要なイベントとしては、電源オンがありますが、明日 10:05:36 に電源をオンにすることは、電源オン イベントのインスタンスに過ぎません。

イベントには関連するパラメータを設定できるため、イベント インスタンスは、興味深いインシデントの発生を伝えるだけでなく、その発生に関する定量的な情報も伝えることができます。たとえば、コンピューターのキーボードのキーを押すことで生成されるキーストローク イベントには、文字スキャン コードと、Shift、Ctrl、および Alt キーの状態を伝える関連するパラメータがあります。

イベント インスタンスは、それを生成した瞬間的な発生よりも長く存続し、この発生を 1 つ以上のステート マシンに伝えることがあります。イベント インスタンスは、生成されると、最大 3 つのステージで構成される処理ライフ サイクルを経ます。最初に、イベント インスタンスは受け入れられ、処理を待機しているときに受信されます(たとえば、イベント キューに配置されます)。その後、イベント インスタンスはステート マシンにディスパッチされ、その時点で現在のイベントになります。最後に、ステート マシンがイベント インスタンスの処理を終了すると、イベント インスタンスは消費されます。消費されたイベント インスタンスは、処理に使用できなくなります。

各ステート マシンには状態があり、これによってステート マシンのイベントへの反応が決まります。たとえば、キーボードのキーを押すと、Caps Lock がアクティブかどうかに応じて、大文字または小文字の文字コードが生成されます。したがって、キーボードの動作は、「デフォルト」状態と「caps_locked」状態の 2 つの状態に分けられます。(ほとんどのキーボードには、キーボードが「caps_locked」状態であることを示す LED が付いています。) キーボードの動作は、履歴の特定の側面、つまり Caps Lock キーが押されたかどうかにのみ依存し、たとえば、以前に押された他のキーの数や正確なキーには依存しません。状態は、考えられるすべての (ただし無関係な) イベント シーケンスを抽象化し、関連するシーケンスのみをキャプチャできます。

ソフトウェア ステート マシン (特に従来の FSM) のコンテキストでは、状態という用語は、事前に決定された限られた数の値 (たとえば、キーボードの場合は 2 つの値、またはより一般的には、多くのプログラミング言語の列挙型を持つ何らかの変数)のみを想定できる単一の状態変数として理解されることがよくあります。状態変数(および従来の FSM モデル) の考え方は、状態変数の値が、任意の時点でのシステムの現在の状態を完全に定義するというものです。状態の概念により、コード内の実行コンテキストを識別する問題が、多くの変数ではなく状態変数のみをテストすることに軽減され、条件付きロジックが大幅に削減されます。

しかし実際には、状態マシンの状態全体を単一の状態変数として解釈することは、非常に単純な状態マシン以外ではすぐに非現実的になります。実際、マシン状態に 32 ビットの整数が 1 つあるだけでも、40 億を超えるさまざまな状態の原因となる可能性があり、状態が急激に増加します。この解釈は現実的ではないため、UML 状態マシンでは、状態マシンの状態全体が (a) 列挙可能な状態変数と (b) 拡張状態と呼ばれるその他のすべての変数に分割されるのが一般的です。別の見方としては、列挙可能な状態変数を状態全体の質的側面として解釈し、拡張状態を量的側面として解釈する方法があります。この解釈では、変数の変更は必ずしもシステム動作の質的側面の変更を意味するとは限らず、したがって状態の変更にはつながりません。^[7]

拡張状態変数が追加されたステート マシンは拡張ステート マシンと呼ばれ、UML ステート マシンはこのカテゴリに属します。拡張ステート マシンは、拡張状態変数を含めない場合よりも、はるかに複雑な問題に基礎となる形式を適用できます。たとえば、FSM に何らかの制限を実装する必要がある場合 (キーボードのキー入力回数を 1000 回に制限するなど)、拡張状態がなければ1000 個の状態を作成して処理する必要がありますが、これは現実的ではありません。ただし、拡張ステート マシンを使用すると、 1000 に初期化され、状態変数をkey_count変更せずにキー入力ごとに減分される変数を導入できます。

図 2 の状態図は拡張状態マシンの例であり、システムの完全な状態 (拡張状態と呼ばれる) は、質的側面 (状態変数)と量的側面 (拡張状態変数)の組み合わせです。

拡張ステート マシンの明らかな利点は柔軟性です。たとえば、キーストロークの制限をkey_count1000 から 10000 に変更しても、拡張ステート マシンはまったく複雑になりません。必要な変更は、初期化中に拡張ステート変数の初期化値を変更することだけですkey_count。

ただし、拡張ステート マシンのこの柔軟性には、拡張ステートの「質的」側面と「量的」側面の間の複雑な結合のために、代償が伴います。図 2 に示すように、この結合は遷移に付加されたガード条件を通じて発生します。

ガード条件(または単にガード) は、拡張された状態変数とイベント パラメータの値に基づいて動的に評価されるブール式です。ガード条件は、アクションまたは遷移が TRUE と評価された場合にのみ有効にし、FALSE と評価された場合にのみ無効にすることで、ステート マシンの動作に影響を与えます。UML 表記では、ガード条件は角括弧で示されます (例:[key_count == 0]図 2)。

ガードの必要性は、メモリ拡張状態変数をステートマシン形式に追加したことによる直接的な結果です。拡張状態変数とガードは控えめに使用すると、設計を簡素化できる強力なメカニズムになります。その一方で、拡張状態とガードは簡単に悪用される可能性があります。^[8]

イベント インスタンスがディスパッチされると、ステート マシンは、変数の変更、I/O の実行、関数の呼び出し、別のイベント インスタンスの生成、別の状態への変更などのアクションを実行して応答します。現在のイベントに関連付けられているすべてのパラメーター値は、そのイベントによって直接発生するすべてのアクションで使用できます。

ある状態から別の状態に切り替えることを状態遷移 と呼び、その原因となるイベントを トリガー イベント 、または単にトリガーと呼びます。キーボードの例では、キーボードが「デフォルト」状態のときに CapsLock キーを押すと、キーボードは「caps_locked」状態になります。ただし、キーボードがすでに「caps_locked」状態である場合、CapsLock キーを押すと、「caps_locked」状態から「デフォルト」状態への別の遷移が発生します。どちらの場合も、CapsLock キーを押すことがトリガー イベントです。

拡張ステート マシンでは、遷移にガードを設定できます。つまり、ガードが TRUE と評価された場合のみ遷移が「発動」します。ガードが重複していない限り、ステートには同じトリガーに応答する遷移が複数設定できます。ただし、この状況では、共通のトリガーが発生したときにガードの評価順序に問題が生じる可能性があります。UML 仕様^[1] では、意図的に特定の順序を規定していません。むしろ、UML では、ガードの評価順序が重要にならないようにガードを設計する負担を設計者に課しています。実際には、ガード式には副作用がなく、少なくとも同じトリガーを持つ他のガードの評価を変更する副作用があってはなりません。

UML ステート マシンを含むすべてのステート マシン形式では、ステート マシンが各イベントの処理を完了してから次のイベントの処理を開始すると一般的に想定されています。この実行モデルは、完了まで実行(RTC) と呼ばれます。

RTC モデルでは、システムはイベントを個別の分割不可能な RTC ステップで処理します。新しい着信イベントは現在のイベントの処理を中断することはできず、ステート マシンが再びアイドル状態になるまで (通常はイベント キューに) 保存する必要があります。これらのセマンティクスにより、単一のステート マシン内での内部同時実行の問題が完全に回避されます。RTC モデルでは、遷移に関連付けられたアクションの処理の概念的な問題も回避されます。この処理では、アクションの期間中、ステート マシンは明確に定義された状態 (2 つの状態の間) にありません。イベント処理中、システムは応答しない (観察できない) ため、その間の明確に定義されていない状態は実際には意味を持ちません。

ただし、RTC は、RTC ステップが完了するまでステート マシンが CPU を独占しなければならないことを意味するわけではないことに注意してください。^[1] プリエンプションの制限は、すでにイベントの処理でビジー状態になっているステート マシンのタスク コンテキストにのみ適用されます。マルチタスク環境では、他のタスク (ビジー状態になっているステート マシンのタスク コンテキストとは関係のないタスク) が実行され、現在実行中のステート マシンをプリエンプトする可能性があります。他のステート マシンが変数やその他のリソースを相互に共有しない限り、同時実行の危険性はありません。

RTC 処理の主な利点はシンプルさです。最大の欠点は、ステート マシンの応答性が最長の RTC ステップによって決まることです。RTC ステップを短くすると、リアルタイム設計が著しく複雑になることがよくあります。

従来の FSM は小規模な問題に取り組むための優れたツールですが、中程度に複雑なシステムであっても管理不能になる傾向があることも一般的に知られています。状態と遷移の爆発と呼ばれる現象により、従来の FSM の複雑さは、それが記述するシステムの複雑さよりもはるかに速く増大する傾向があります。これは、従来の状態マシンの形式主義が繰り返しを引き起こすために発生します。たとえば、従来の FSM を使用して単純なポケット電卓の動作を表現しようとすると、多くのイベント (たとえば、クリア ボタンまたはオフ ボタンの押下) が多くの状態で同じように処理されることにすぐに気付くでしょう。下の図に示す従来の FSM には、このような共通性を捉える手段がなく、多くの状態で同じアクションと遷移を繰り返す必要があります。従来の状態マシンに欠けているのは、共通の動作をくくり出して多くの状態で共有するためのメカニズムです。

UML ステート マシンは、まさにこの従来の FSM の欠点を解決します。UML ステート マシンは、繰り返しを排除するさまざまな機能を備えているため、UML ステート マシンの複雑さが爆発的に増加することはなく、記述するリアクティブ システムの複雑さを忠実に表現する傾向があります。言うまでもなく、これらの機能はソフトウェア開発者にとって非常に興味深いものです。なぜなら、これらの機能によってのみ、ステート マシン アプローチ全体が実際の問題に真に適用可能になるからです。

従来の FSMに対する UML ステート マシンの最も重要な革新は、階層的にネストされた状態の導入です(そのため、ステートチャートは階層的ステート マシン、またはHSMとも呼ばれます)。 ステート ネストに関連するセマンティクスは次のとおりです (図 3 を参照)。 システムがネストされた状態、たとえば「result」(サブステートと呼ばれる) にある場合、そのシステムは (暗黙的に) 周囲の状態「on」(スーパーステートと呼ばれる) にもあります。 このステート マシンは、概念的には階層の下位レベルにあるサブステートのコンテキストですべてのイベントを処理しようとします。 ただし、サブステート「result」がイベントの処理方法を規定していない場合、イベントは従来の「フラット」ステート マシンのように静かに破棄されるのではなく、スーパーステート「on」の上位レベルのコンテキストで自動的に処理されます。 これが、システムが状態「result」と「on」の両方にあるという意味です。もちろん、状態のネスト化は 1 つのレベルだけに限定されず、イベント処理の単純なルールは、どのレベルのネスト化にも再帰的に適用されます。

他の状態を含む状態は複合状態と呼ばれます。逆に、内部構造を持たない状態は単純状態と呼ばれます。ネストされた状態は、他の状態に含まれていない場合は直接サブ状態と呼ばれ、そうでない場合は推移的にネストされたサブ状態と呼ばれます。

複合状態の内部構造は任意に複雑になる可能性があるため、階層型ステートマシンは、何らかの（高レベルの）複合状態の内部構造として見ることができます。 1 つの複合状態をステートマシン階層の最終的なルートとして定義すると、概念的に便利です。 UML 仕様では、すべてのステートマシンに領域（すべてのステートマシン階層の抽象ルート）があり、^[9]ステートマシン全体の他のすべての要素が含まれています。 このすべてを囲む領域のグラフィカルなレンダリングはオプションです。

ご覧のとおり、階層的状態分解のセマンティクスは、動作の再利用を容易にするように設計されています。サブ状態（ネストされた状態）は、スーパー状態（包含状態）との差異を定義するだけで済みます。サブ状態は、共通して処理されるイベントを無視するだけで、スーパー状態から共通の動作を簡単に継承できます^[6]。これらのイベントは、上位レベルの状態によって自動的に処理されます。言い換えれば、階層的状態のネストにより、差異によるプログラミングが可能になります。^[10]

状態階層で最も頻繁に強調される側面は抽象化です。これは、複雑性に対処するための古くからある強力な手法です。複雑なシステムのすべての側面に同時に対処する代わりに、システムの一部を無視 (抽象化) できる場合がよくあります。階層状態は、設計者が簡単にズーム アウトまたはズーム インしてネストされた状態を表示または非表示にできるため、内部の詳細を隠すための理想的なメカニズムです。

ただし、複合状態は単に複雑さを隠すだけでなく、階層型イベント処理の強力なメカニズムを通じて複雑さを積極的に軽減します。このような再利用がなければ、システムの複雑さが中程度に増加しただけでも、状態と遷移の数が爆発的に増加する可能性があります。たとえば、ポケット電卓を表す階層型状態マシン (図 3) は、事実上すべての状態で Clear と Off の遷移を繰り返さないようにします。繰り返しを回避することで、HSM の成長をシステムの複雑さの増加に比例させることができます。モデル化されたシステムが成長するにつれて、再利用の機会も増えるため、従来の FSM に典型的な状態と遷移の数が不均衡に増加するのを潜在的に相殺できます。

階層的状態分解による分析には、任意の状態への「排他的論理和」演算の適用が含まれます。たとえば、システムが「オン」スーパーステート (図 3) にある場合、「オペランド 1」サブステートまたは「オペランド 2」サブステートまたは「opEntered」サブステートまたは「結果」サブステートのいずれかにある可能性があります。これにより、「オン」スーパーステートは「OR 状態」として記述されます。

UMLステートチャートでは、補完的なAND分解も導入されています。このような分解は、複合状態が2つ以上の直交領域（この文脈では、直交とは互換性があり独立していることを意味します）を含むことができ、そのような複合状態にあるということは、そのすべての直交領域に同時に存在することを意味します。^[11]

直交領域は、システムの動作が独立した同時にアクティブな部分に細分化されている場合に、状態の数の組み合わせが増加するというよくある問題に対処します。たとえば、メイン キーパッドとは別に、コンピューターのキーボードには独立した数字キーパッドがあります。前の説明で、メイン キーパッドの 2 つの状態が既に特定されていることを思い出してください。「デフォルト」と「caps_locked」です (図 1 を参照)。数字キーパッドも、Num Lock がアクティブかどうかに応じて、「数字」と「矢印」の 2 つの状態になります。したがって、標準分解におけるキーボードの完全な状態空間は、2 つのコンポーネント (メイン キーパッドと数字キーパッド) の直積であり、「デフォルト - 数字」、「デフォルト - 矢印」、「caps_locked - 数字」、「caps_locked - 矢印」の 4 つの状態で構成されます。ただし、数字キーパッドの動作はメイン キーパッドの状態には依存せず、その逆も同様であるため、これは不自然な表現になります。直交領域を使用すると、図 4 に示すように、独立した動作が直交積として混在することを回避し、代わりにそれらを分離したままにすることができます。

直交領域が互いに完全に独立している場合、それらの合計複雑度は単純に加算されることに注意してください。つまり、システムをモデル化するために必要な独立状態の数は、単純に合計k + l + m + ...になります。ここで、k、l、m、...は、各直交領域の OR 状態の数を表します。ただし、一方、相互依存性の一般的なケースでは、乗法的な複雑度が生じるため、一般的に、必要な状態の数は積k × l × m × ... になります。

実際のほとんどの状況では、直交領域はほぼ直交しているだけです (つまり、完全に独立しているわけではありません)。したがって、UML ステートチャートは、直交領域が通信して動作を同期するためのさまざまな方法を提供します。これらの豊富な (場合によっては複雑な) メカニズムの中で、おそらく最も重要な機能は、直交領域がイベント インスタンスを相互に送信することで動作を調整できることです。

直交領域は実行の独立性（多かれ少なかれ同時実行を可能にする）を意味するが、UML仕様では各直交領域に別々の実行スレッドを割り当てることを要求していない（ただし、必要に応じてこれを行うことは可能）。実際、最も一般的には、直交領域は同じスレッド内で実行される。^[12] UML仕様では、設計者がイベントインスタンスを関連する直交領域にディスパッチするための特定の順序に依存しないことのみを要求している。

UML ステートチャートの各状態には、オプションのエントリ アクション(状態に入るときに実行される) とオプションの終了アクション(状態から出るときに実行される) を設定できます。エントリ アクションと終了アクションは、遷移ではなく状態に関連付けられます。状態に入る方法や状態から出る方法に関係なく、すべてのエントリ アクションと終了アクションが実行されます。この特性により、ステートチャートはムーア マシンのように動作します。状態のエントリ アクションと終了アクションの UML 表記では、名前コンパートメントのすぐ下の状態に予約語 "entry" (または "exit") を配置し、その後にスラッシュと任意のアクションのリストを続けます (図 5 を参照)。

エントリ アクションと終了アクションの価値は、オブジェクト指向プログラミングのクラス コンストラクターとデストラクタと非常によく似た、保証された初期化とクリーンアップの手段を提供することです。たとえば、図 5 の「door_open」状態を考えてみましょう。これは、ドアが開いているときのトースター オーブンの動作に対応しています。この状態には非常に重要な安全性要件があります。ドアが開いているときは常にヒーターを無効にする必要があります。さらに、ドアが開いているときは、オーブンを照らす内部ランプが点灯する必要があります。

もちろん、このような動作は、適切なアクション (ヒーターを無効にしてライトをオンにする) を "door_open" 状態 (ユーザーは "ベーキング" または "トースト" 中、またはオーブンがまったく使用されていないときにいつでもドアを開けることができます) につながるすべての遷移パスに追加することでモデル化できます。"door_open" 状態から出るすべての遷移で内部ランプを消すことを忘れてはなりません。ただし、このようなソリューションでは、多くの遷移でアクションが繰り返されます。さらに重要なことは、このようなアプローチでは、その後の動作の修正時に設計エラーが発生しやすくなることです (たとえば、トップ ブラウンニングなどの新しい機能に取り組んでいる次のプログラマーは、"door_open" への遷移でヒーターを無効にすることを単に忘れる可能性があります)。

エントリ アクションと終了アクションを使用すると、より安全で、よりシンプル、かつより直感的な方法で、目的の動作を実装できます。図 5 に示すように、「加熱」からの終了アクションでヒーターが無効になり、「ドアを開く」へのエントリ アクションでオーブンのランプが点灯し、「ドアを開く」からの終了アクションでランプが消えるように指定できます。エントリ アクションと終了アクションの使用は、アクションを遷移に配置するよりも望ましい方法です。繰り返しのコーディングを避け、安全上の危険 (ドアが開いている間ヒーターがオン) を排除することで機能を向上させるためです。終了アクションのセマンティクスにより、遷移パスに関係なく、トースターが「加熱」状態でない場合はヒーターが無効になることが保証されます。

エントリ アクションは、関連付けられた状態に入るたびに自動的に実行されるため、クラス コンストラクターが構築されるオブジェクトの ID を決定するのと非常によく似ており、多くの場合、エントリ アクションによって操作の条件または状態の ID が決定されます。たとえば、「加熱」状態の ID は、ヒーターがオンになっているという事実によって決定されます。この条件は、「加熱」のサブ状態に入る前に確立される必要があります。これは、「トースト」などの「加熱」のサブ状態へのエントリ アクションが、「加熱」スーパー状態の適切な初期化に依存し、この初期化との差分のみを実行するためです。したがって、エントリ アクションの実行順序は、常に最も外側の状態から最も内側の状態 (トップダウン) に進む必要があります。

当然のことながら、この順序はクラス コンストラクターが呼び出される順序に似ています。クラスの構築は常にクラス階層のルートから始まり、インスタンス化されるクラスまですべての継承レベルをたどります。デストラクタの呼び出しに対応する終了アクションの実行は、まったく逆の順序 (ボトムアップ) で進行します。

非常に一般的には、イベントによって一部の内部アクションのみが実行されますが、状態の変更 (状態遷移) は発生しません。この場合、実行されるすべてのアクションが内部遷移を構成します。たとえば、キーボードで入力すると、異なる文字コードが生成されて応答します。ただし、Caps Lock キーが押されない限り、キーボードの状態は変化しません (状態遷移は発生しません)。UML では、図 6 に示すように、この状況は内部遷移を使用してモデル化する必要があります。内部遷移の UML 表記は、終了 (またはエントリ) アクションに使用される一般的な構文に従いますが、エントリ (または終了) という単語の代わりに、内部遷移にトリガー イベントのラベルが付けられます (たとえば、図 6 の ANY_KEY イベントによってトリガーされる内部遷移を参照してください)。

エントリ アクションと終了アクションがない場合、内部遷移は自己遷移(ターゲット状態がソース状態と同じである遷移) と同一になります。実際、従来のMealy マシンでは、アクションは状態遷移にのみ関連付けられているため、状態を変更せずにアクションを実行する唯一の方法は自己遷移 (この記事の冒頭の図 1 で有向ループとして表示) です。ただし、UML ステートチャートのようにエントリ アクションと終了アクションがある場合、自己遷移には終了アクションとエントリ アクションの実行が含まれるため、内部遷移とは明確に異なります。

自己遷移とは対照的に、内部遷移が現在アクティブな状態よりも高い階層レベルから継承された場合でも、内部遷移の結果としてエントリ アクションまたは終了アクションが実行されることはありません。ネスト レベルのスーパー状態から継承された内部遷移は、現在アクティブな状態で直接定義されているかのように動作します。

状態のネストとエントリおよび終了アクションの組み合わせにより、HSM の状態遷移セマンティクスは従来の FSM に比べて大幅に複雑になります。階層的にネストされた状態と直交領域を扱う場合、現在の状態という単純な用語は非常にわかりにくい場合があります。HSM では、複数の状態が同時にアクティブになることがあります。状態マシンが複合状態 (さらに上位レベルの複合状態などに含まれる可能性があります) に含まれるリーフ状態にある場合、リーフ状態を直接または推移的に含むすべての複合状態もアクティブになります。さらに、この階層内の複合状態の一部には直交領域がある場合があるため、現在のアクティブ状態は実際には、ルートの単一領域からリーフの個々の単純状態までの状態ツリーで表されます。UML 仕様では、このような状態ツリーを状態構成と呼びます。^[1]

UML では、状態遷移は任意の 2 つの状態を直接接続できます。これらの 2 つの状態は複合状態である可能性があり、遷移の主なソースと主なターゲットとして指定されます。図 7 は、単純な遷移の例を示し、その遷移における状態の役割を説明しています。UML 仕様では、状態遷移を行うには、次の定義済みシーケンスでアクションを実行する必要があると規定されています ( OMG 統一モデリング言語 (OMG UML) ^[1]のセクション 14.2.3.9.6 を参照)。

1. 遷移に関連付けられたガード条件を評価し、ガードが TRUE と評価された場合にのみ次の手順を実行します。
2. ソース状態の構成を終了します。
3. 遷移に関連付けられたアクションを実行します。
4. ターゲット状態の構成を入力します。

メイン ソースとメイン ターゲットの両方が同じレベルでネストされている単純なケースでは、遷移シーケンスの解釈は簡単です。たとえば、図 7 に示す遷移 T1 では、ガードが TRUE と評価されると仮定して、ガード g(); の評価に続いてアクション シーケンスa(); b(); t(); c(); d();およびe();が実行されますg()。

ただし、ソース状態とターゲット状態が状態階層の異なるレベルにネストされている一般的なケースでは、何レベルのネストから抜け出さなければならないかがすぐにはわからない場合があります。UML 仕様^[1] では、遷移には、現在のアクティブ状態 (メイン ソース状態の直接または推移的なサブ状態である可能性があります) から、メイン ソース状態とメイン ターゲット状態の最小共通祖先(LCA) 状態まで (ただし、LCA 状態は含みません) のすべてのネストされた状態から抜け出すことが含まれると規定されています。名前が示すように、LCA は、ソース状態とターゲット状態の両方のスーパー状態 (祖先) である最下位の複合状態です。前述のように、終了アクションの実行順序は常に、最も深くネストされた状態 (現在のアクティブ状態) から階層を上って LCA までですが、LCA から抜け出すことはありません。たとえば、図 7 に示す状態 "s1" と "s2" の LCA(s1,s2) は状態 "s" です。

ターゲット状態構成への入力は、終了アクションが終了したレベル (つまり、LCA 内) から開始されます。前述のように、エントリ アクションは、最上位の状態から状態階層を下ってメイン ターゲット状態まで実行する必要があります。メイン ターゲット状態が複合状態である場合、UML セマンティクスでは、ローカル初期遷移を使用してサブマシンに再帰的に「ドリルダウン」するように規定されています。ターゲット状態構成に完全に入るのは、初期遷移のないリーフ状態に遭遇した後のみです。

UML 2 より前^[1]では、 使用されている唯一の遷移セマンティクスは外部遷移であり、このセマンティクスでは、遷移のメインソースは常に終了し、遷移のメインターゲットは常に開始されます。UML 2 は下位互換性のために「外部遷移」セマンティクスを保持しましたが、ローカル遷移と呼ばれる新しい種類の遷移も導入しました ( Unified Modeling Language (UML) ^[1]のセクション 14.2.3.4.4 を参照)。多くの遷移トポロジでは、外部遷移とローカル遷移は実際には同一です。ただし、メインターゲット状態がメインソースのサブ状態である場合、ローカル遷移ではメインソース状態からの終了とメインソース状態への再入は発生しません。さらに、メインターゲットがメインソース状態のスーパー状態である場合、ローカル状態遷移ではメインターゲット状態からの終了とメインターゲット状態への再入は発生しません。

図 8 は、ローカル (a) 遷移と外部 (b) 遷移を対比しています。上の行は、メイン ソースにメイン ターゲットが含まれている場合を示しています。ローカル遷移ではソースから出ませんが、外部遷移ではソースから出てソースに再入します。図 8 の下の行は、メイン ターゲットにメイン ソースが含まれている場合を示しています。ローカル遷移ではターゲットにエントリしませんが、外部遷移ではターゲットから出てターゲットに再入します。

時々、イベントは、ステート マシンがイベントを処理できない状態にある、特に都合の悪いタイミングで発生することがあります。多くの場合、イベントの性質上、システムが別の状態になり、元のイベントをより適切に処理できるようになるまで、イベントを (制限内で) 延期することができます。

UML ステート マシンは、状態内のイベントを延期するための特別なメカニズムを提供します。すべての状態で、句を含めることができます[event list]/defer。現在の状態の延期イベント リスト内のイベントが発生した場合、そのイベントは、延期イベント リストにそのイベントが含まれていない状態になるまで、将来の処理のために保存 (延期) されます。そのような状態に入ると、UML ステート マシンは、延期されなくなった保存済みイベントを自動的に呼び出し、これらのイベントを消費または破棄します。サブ状態によって延期されたイベントに対して、スーパーステートに遷移を定義することができます。UML ステート マシンの仕様の他の部分と同様に、サブステートはスーパーステートよりも優先され、イベントは延期され、スーパーステートの遷移は実行されません。1 つの直交領域がイベントを延期し、別の直交領域がそのイベントを消費する直交領域の場合、コンシューマーが優先され、イベントは消費され、延期されません。

UML ステート マシンの前身である Harel ステートチャートは、「複雑なシステムの視覚的な形式」として発明されました^[2]。そのため、当初から、ステート ダイアグラム形式のグラフィカルな表現と切り離すことはできませんでした。ただし、UML ステート マシンの概念は、グラフィカルまたはテキストの特定の表記法を超えていることを理解することが重要です。UML 仕様^[1]では、 ステート マシンのセマンティクスと表記法を明確に区別することで、この区別を明確にしています。

しかし、UML ステートチャートの表記法は純粋に視覚的なものではありません。重要なステートマシンには、大量のテキスト情報 (アクションやガードなどの仕様) が必要です。アクションとガードの式の正確な構文は UML 仕様では定義されていないため、多くの人は構造化された英語を使用するか、より正式にはC、C++、Javaなどの実装言語の式を使用します。^{[13]実際には、これは UML ステートチャートの表記法が特定の}プログラミング言語に大きく依存することを意味します。

それでも、ステートチャートのセマンティクスのほとんどは、グラフィカル表記に大きく偏っています。たとえば、状態図では、ガード評価の順序や直交領域へのイベントのディスパッチ順序など、処理の順序が適切に表現されません。UML 仕様では、設計者に特定の順序付けに依存しないように義務を課すことで、これらの問題を回避しています。ただし、UML ステート マシンが実際に実装されると、実行順序を完全に制御する必要が生じ、UML セマンティクスが不必要に制限的であるという批判が生じます。同様に、ステートチャート図では、制御フローをグラフィカルに表現するために、多くの配管装置 (結合、フォーク、ジャンクション、選択ポイントなどの疑似状態) が必要です。言い換えると、グラフィカル表記のこれらの要素は、単純な構造化コードと比較して、制御フローを表現する上であまり価値を追加しません。

UML 表記法とセマンティクスは、実際にはコンピューター化されたUML ツール向けに作られています。ツールで表現される UML ステート マシンは、単なるステート ダイアグラムではなく、ステート トポロジとアクションの両方を正確に捉えたグラフィカル表現とテキスト表現の組み合わせです。ツールのユーザーは、同じステート マシンの複数の補完的なビュー (ビジュアルとテキストの両方) を取得できますが、生成されたコードは、利用可能な多数のビューの 1 つにすぎません。

• 統一モデリング言語 2.5.1。OMG文書番号 formal/2017-12-05。オブジェクト管理グループ標準化機構 (OMG SDO)。2017 年 12 月。

• UML 2 ステートマシン図