2

UML 2.5 ステート マシン図のすべての基本要素を特定する必要があります。残念ながら、オンラインにはさまざまなバリエーションがあるため、これらの図の表記にはあいまいな点が多いようです。

私の解釈では、すべてのステート マシン図は、多数の状態と多数の遷移で構成されています。

すべての州には次のものがあります。

  • オプションのエントリアクション
  • オプションのdoアクション
  • オプションの終了アクション

すべてのトランジションには次のものがあります。

  • トリガーイベント_
  • オプションの前提条件
  • 遷移アクション(事後条件) 。

この表記法がどのように機能するかについての私の理解は、図 1 ( [前提条件] イベント / [遷移アクション]表記法に従った電動ドア機能の例) と図 2 に要約できます。

例:イベントがトリガーされると (例: 閉じるボタンが押される)、前提条件(存在する場合) が評価され (例: 出入り口が空である)、前提条件が満たされると、遷移アクション(例: ドアを閉じる) がトリガーされます。

図1 電気ドア ステート マシン

図 2 ここに画像の説明を入力

私の質問:

  1. 遷移アクションは、遷移の実現ですか、それとも単に遷移中に発生するアクションですか。簡単に言えば、遷移アクションが失敗した場合、遷移 (新しい状態) は成功しますか? 私の質問は基本的に、多くの情報源が、移行アクションを使用する代わりに、新しい状態に到達したときにエントリ アクションを使用できることを示唆しているという事実に由来しています。私の理解では、移行アクションは移行の実現であるため、エントリ アクションと比較して、新しい状態に入る前に発生します。これは、新しい状態に到達した直後に発生します。したがって、これらは遷移自体と時間に関して、2 つのまったく異なるタイプのアクションです。ここでは、これらのアクションのタイミングを理解することが重要です。
  2. 私の一般的な解釈は正しいですか？(たとえば、図 1 から、イベント、事後条件、および遷移アクションが何であるかについての私の理解)

ステートマシン図には数十のバリエーションがあることを知っています。したがって、さまざまな表現/解釈がありますが、UML 2.5 に興味があります。

4

1 に答える 1

2

遷移アクションは、UML 2.5 が遷移の関連終了として述べているものです。

effect : Behavior [0..1]{subsets Element::ownedElement} (反対 A_effect_transition::transition) Transition が発生したときに実行されるオプションの動作を指定します。

状態の<<entry>>は、状態自体に割り当てられた動作です。つまり、トランジションが発生した場所からトリガーされます。対照的に、上記の効果はトランジションに沿ってのみトリガーされます。

その効果は「うまくいかない」ことはありません。どんな行動が実行されても、実行されます。ここでは条件はチェックされません。

トランジションがトリガーされるかどうかは、[guard]間違って名前を付けた によって制御できます[precondition]。（議論を始めることはできますが、一緒に行く必要があります[guard]。）

guard : Constraint [0..1]{subsets Namespace::ownedRule} (反対 A_guard_transition::transition) ガードは、遷移の起動をきめ細かく制御する制約です。StateMachine によって Event オカレンスがディスパッチされると、ガードが評価されます。その時点でガードが true の場合、遷移は有効になる可能性があり、そうでない場合は無効になります。ガードは、副作用のない純粋な式である必要があります。副作用のあるガード式は形式が正しくありません。

タイミングに関しては、州に沿って移動するトークンを考えることができます。ガードがあなたを通過させると、<<exit>>動作が実行されます。次に、遷移のeffect、最後に<<entry>>次の状態の動作です。

于 2016-04-23T13:13:15.053 に答える