IBM® Rational® Rhapsody® はガードを解釈しません。 ガードは、ホスト環境の言語式または簡単なコードでなければならず、結果をテストできるように、ブール値または整数値として解釈される必要があります。そうでないと、 ガード用に生成されたステートチャート・コードが正しくコンパイルされません。
以下の例では、 イベントの生成に GEN マクロを使用するアクションとガードで構成される、遷移ラベルを示します。
[x > 7]/controller->GEN(A7Failures)
遷移をガードのみで構成することもできます。条件 (またはブール値) の low-to-high 遷移は、トリガー・イベントと考えられます。例えば、以下のガードは有効な遷移ラベルです。
[x > 7]
アニメーション中、トリガーなしのガードはすべて、イベントが発生するごとにテストされます。以下のステートチャートは、遷移なしのガードをいくつか使用します。

このステートチャートは、住宅用警報装置のキーパッドのものです。警報装置のキーパッドがアイドル状態のときに、外出する前に警報を設定するコードを入力できます。コードを入力した後、 「オン」ボタンを押して、警報をオンにします。On ボタンを押すと、evKeyOn イベントが発行されます。このイベントが発生するごとに、 デシジョン・ノードの後の 2 つのガード、[IS_IN(correct)] または [IS_IN(notEntered)] を状態マシンが評価し、true と判断される方のパスをとります。
アニメーション化されたシーケンス図を使用すると、ガードがいつテストされるかがわかります。イベント発生ごとではなく、条件をより頻繁にテストする場合、またはより規則正しい間隔でテストする場合は、ポーリング・メカニズムを作成できます。このためには、少なくともタイムアウトが発生するごとにガードが評価されるようにその状態から自身への短いタイムアウト遷移を作成します。または、別のオブジェクトを使用してポーリングし、現在のステートチャート内のガードをポーリング・オブジェクトから合図されたイベントで置き換えることができます。