選択肢セグメントの追加
ステートマシンでは、特定の条件(guard conditionと呼ばれる)が実行時にTRUEと評価された場合にのみ、状態遷移を行う必要があることがよくあります。 また、多くの場合、実行時に評価されたいくつかのガード条件の結果に応じて、異なる状態に移行する必要があります。
UMLは、このような状況で使用できる”choice pseudostate”と呼ばれる特別な構造を提供します。 “Choice pseudostate”を使用すると、トランジションを複数の発信パスに分割することができます。
注上の図のパネル(B)に示されているような選択擬似ステートについては、compoundif (guard1()) {...} else if (guard2()) {...}
ステートメントのように考えると便利です(これは、QM™コードジェネレータが選択セグ 注意ガードはコード内でIF
とELSE
につながるため、それらを過度に使用すると”スパゲッティ”コードにつながり、最初に状態マシンを使用する目的に反します。 そのため、警備員は慎重に使用する必要があります。
ほとんどのUMLツールでは、選択肢セグメントを描画するプロセスは、最初に”選択肢擬似ステート”(ダイヤモンド)を追加し、次にガード付きの発信遷移セグ Qm™では、State Machine Toolboxにすぐに使用できるChoice Segmentツールが含まれており、”choice pseudostate”と遷移セグメントを永続的にアタッチしたものを組み合わせているため、このプロセ
注Choice Segmentは、上の図のパネル(A)に示すように、qm™でガード条件をトランジションにアタッチする唯一の方法です。 しかし、QM™Choiceセグメントは、次のセクションで説明するように、トランジションの単純なガードよりも強力です。 注選択肢セグメントを追加するには、まず状態図を作成して表示する必要があります。 さらに、ステートマシンは、少なくとも一つの内部遷移(で終了)または選択セグメント()を持たなければならない。 最後に、選択セグメントを追加、移動、サイズ変更、または編集するには、ステートマシン図をロック解除する必要があります()。
ステートマシンのサブウィンドウがアクティブであることを確認します。 State Machine Toolboxでセグメント選択ツールをクリックし、マウスボタンを離します(ツールバーからツールをドラッグしないでください)。 この時点で、アクティブステートダイアグラムの上にマウスを置くと、マウスポインタは”禁止”アイコン()付きのchoice-segmentツールに変わります。 Choice-segmentに許可されているアタッチメントポイントの上にマウスを置くと、マウスポインタはアンカー()を使用してchoice segmentツールに変わります。 このアタッチメントポイントに選択セグメントを追加するには、マウスボタンを押して、選択セグメントの端をターゲット状態の目的の端までドラッ このようにして確立された遷移経路は、ガードを有する通常の状態から状態への遷移に対応するであろう。
また、ガードを使用して内部遷移になる選択肢セグメントを追加することもできます。 これを行うには、選択セグメントの端をドラッグして、ステートエッジにドロップしないようにします。 この時点で、choice-segmentは内部遷移になります。 内部遷移は完全にソース状態内で実行され、状態の変化につながることはありません。
標準の”規範的”UML表記では、内部遷移セグメントをchoice pseudostateに追加することはできません。 対照的に、QM™の内部遷移の非規範的表現を使用すると、選択擬似ステートに内部遷移セグメントを簡単に追加したり、遷移端をステートにアタッチ/デ
最後に、下のアニメーションに示すように、別の選択肢セグメントのアタッチされていない端に選択肢セグメントを追加することもできます:
注:既存の選択肢セグメントに選択肢セグメントを追加するこのオプションは、複雑なネストされたガードを構築できることを意味します。 ただし、すべてのガード条件と同様に、この機能を慎重に使用して、”スパゲッティ”コードを回避する必要があります。
選択セグメント項目は、選択固有のプロパティシートで設定できます。
Choice Segment property sheetには、次のプロパティが含まれています:
- Choice Guard
- Choice Target(編集不可–幾何学的に決定)
- Choice Action
Choice Guard
QM™内のすべてのchoiceセグメントには、pseudocodeとcodeの二つのエントリで構成される明示的なguardプロパティが必要です。 コード生成に関連するのは、guardプロパティのコードエントリのみです。 擬似コードエントリは、遷移図形の横に表示するテキストの量を最小限に抑えることによって混乱を避けるために、図に表示されるように設計されて
注意guardプロパティの擬似コードエントリは、choiceセグメントに関連付けられたテキストボックスに表示するためのものですが、コード生成には影響しません。 注意guardプロパティは、トランジションテキストボックスと同じ規則に従って、選択セグメントのテキストボックスに表示されます。 さらに、図の乱雑さを減らすために、ガードは省略形で表示され、ガード内のすべてのスペースが削除され、結果のガードテキストが32文字で切り捨てられます。 (ガードが切り詰められている場合、最後の文字は’~’です)。
コードを正常に生成するには、guardプロパティのコードエントリが正当なCまたはC++ブール式である必要があります。 この式では、(meポインターを介して)ステートマシン属性と、トリガーイベントのイベントパラメーターを使用できます(以下のセクションを参照)。
トリガーイベントへのアクセス: Guard式は、(QEvt const * const)
型のeポインタとして提供される元のトリガーイベント(選択肢が直接または間接的にアタッチされている遷移の)にアクセスできます。 これは、イベントへの読み取り専用アクセス権があり、e
ポインターを変更できないことを意味します。 元のトリガーイベントのイベントパラメータにアクセスするには、通常、イベントポインタeをダウンキャストする必要があります。 このダウンキャストは、常に遷移トリガー(トリガーイベントの信号、遷移トリガーを参照)に基づいているため、トリガーに関連付けられたイベントタイプ(イベン
Choice Target
targetプロパティは直接編集することはできませんが、選択セグメントの終点によって幾何学的に決定されます。 状態から状態への遷移の場合、targetプロパティには、end-point()が終了するターゲット状態が一覧表示されます。 正方形の端点()を持つ内部遷移の場合、targetプロパティにはinternal
が表示されます。
Choice Action
Choiceセグメントは、実行時にガードがTRUEと評価された場合にのみ実行されるオプションのactionプロパティを持つことができます(Action評価の順序も参照)。
アクションプロパティは、擬似コードとコードの二つのエントリで構成されています(Choiceプロパティシートを参照)。 コード生成に関連するのは、actionプロパティのコード部分のみです。 擬似コードフィールドは、遷移図形の横に表示するテキストの量を最小限に抑えることにより、混乱を避けるために、ダイアグラムに表示されるように
注actionプロパティの擬似コードエントリは、ダイアグラム内での表示のみを目的としており、コード生成には影響しません。
トリガーイベントへのポインタ:choiceアクションコードは、多くの場合、タイプ(QEvt const * const)
のeポインタとして提供されるトリガーイベントにアクセスする必要があ これは、イベントへの読み取り専用アクセス権があり、e
ポインターを変更できないことを意味します。 トリガーするイベントのイベントパラメータにアクセスするには、通常、イベントポインタeをダウンキャストする必要があります。 このダウンキャストは、常に遷移トリガー(トリガーイベントの信号、遷移トリガーを参照)に基づいているため、トリガーに関連付けられたイベントタイプ(イベン
選択テキストボックス
選択分節項目を現在の項目として選択すると、選択分節に関連付けられたテキストボックスの境界が表示されます。 テキストボックスを使用すると、選択したテキストをドラッグするか、トランジションテキストボックスと同じアルゴリズムに従ってテキストボッ
else Guard
guardプロパティは、特別なelseキーワードとして定義できます。 このようなelse guardは、同じ選択肢pseudostateに付随する他のguard条件を補完します。 Elseガードは、guardプロパティのコードエントリまたは擬似コードエントリのいずれかで指定できます。 明らかに、”else”ガードは、複数の出てくる選択肢セグメントを持つ選択肢擬似状態に対してのみ意味があります。
注コード生成中、else guardは、モデルエクスプローラーでの順序に関係なく、同じchoice pseudostateに関連付けられているすべてのguardのグループ内で常に最後に生成されます。
choice Segments Without else
UML仕様によれば、すべてのガードがFALSEと評価されたために処理できないイベントは、未処理として扱われなければなりません。 この要件は、明示的なelseセグメントのない選択擬似ステートに影響を与えます。 具体的には、UMLセマンティクスに準拠するために、QM™コードジェネレータは、そのような場合に、スーパーステートへのイベントの伝播を引き起こす暗黙のelse
分岐
空のelseセグメントを持つchoice pseudostateと、elseセグメントを持たないそれ以外の場合は同一のchoice pseudostateには違いがあることに注意してください。 明示的な空のelseはイベントを(何もせずに)消費させ、elseセグメントがない場合はイベントをスーパーステートに伝播させます。
ガード評価の順序
UML仕様では、同じ選択肢擬似状態に付随するガード条件が相互に相補的であることが要求されているため、ガードの評価の順序は重要ではない。 監視を補足保つことがQM™でまだ推薦される間、用具はあなたが頼ることができる前もって決定された順序で監視を常に評価する。
ガード評価の順序は、モデルエクスプローラーの選択セグメント項目の順序によって決まります。 この順序は、エクスプローラツールバーの上ボタンと下ボタンを使用して変更できます。 または、Ctrl-(キーアップ)およびCtrl-(キーダウン)のキーボードショートカットを使用して、モデルエクスプローラー内で現在のアイテムを上下に移動することもできます。
注ガードが重複する場合ガード評価の順序が重要な場合は、上のスクリーンショットに示すように、モデルエクスプローラと同じ順序で図内に選択セグメントをグラフィカルに配置することを強くお勧めします。 生成されたコードは、上の図の右側に示すように、同じ順序に従います。
アクション評価の順序
トランジションにアタッチされた選択肢セグメントは、トランジションによって実行されるアクションに選択肢セグメント これらすべてのアクションの評価の順序は直感的であり、常に無条件に実行される遷移アクションから始まり、その後に選択セグメントアクションの条件付き評価が続きます。
たとえば、上の図のアクション評価の順序は、次の擬似コードによって要約されます:
ネストされた選択肢セグメント
上記のように、選択肢セグメントはネストすることができます。 これにより、複雑な条件付き遷移パスを構築することができますが、いつものようにガードでは、機能を過度に使用すべきではありません。
たとえば、よくある間違いの1つは、深くネストされた選択セグメントを使用して、可能な遷移パスの数から選択することです(下の図のpanel(A)を参照)。):
上の図のパネル(B)に示すように、同じ選択肢擬似ステートに接続された複数の選択肢セグメントを使用する方がより簡単で簡単な代替方法です。
メモ指定されたトランジションには、多くの選択肢セグメントをアタッチできます。 選択肢の数が少ない擬似状態(ダイヤモンド)の図は、より良く、理解しやすい図です。 注意QM™コードジェネレータは、コード内のネストレベルの数を16に制限します(状態ハンドラ関数内のネストを含む)。 深くネストされた選択肢セグメントの使用は、この制限を簡単に超えることができます。
Routing Choice Segments
複数のchoice segmentsを持つ遷移で、そのうちのいくつかはネストされている可能性があり、小さなダイアグラム空間に多くの要素をグループ化します。 このような複雑な”コネクタのボール”をグラフィカルに再配置するには、この状況に適用される基本的なルールを認識する必要があります。
最初のルールは、任意の要素の形状を変更する前に、最初にそれを選択する必要があるということです。たとえば、choice-pseuodstate(ダイヤモンド)を移動する場合は、choice-pseuodstateへの元の着信遷移をクリックする必要があります。 それは実際に着信トランションエンドプラスすべての発信choceセグメントの重複コレクションであるため、あなたは非常に具体的に、ダイヤモンドの形 代わりに、トランジションセグメントまたはトランジションの開始と終了のいずれかをクリックします。 (注:モデルエクスプローラービューで任意のモデル項目を明確に選択することもできます)。 次のアニメーションは、プロセスを示しています:
一方、発信choice-segmentを選択した場合、choice-pseudostateを移動することはできません。 代わりに、選択したchoice-segmentだけを移動して、別の場所に再アタッチすることができます。
Leave a Reply