Book a Demo

Author Topic: SD: Transition Guard is not bound to a trigger  (Read 3041 times)

Emilio

  • EA User
  • **
  • Posts: 78
  • Karma: +0/-0
    • View Profile
SD: Transition Guard is not bound to a trigger
« on: March 20, 2009, 12:16:48 am »
In creating State Charts we all use the transitions to denote the path from a source state to an end state when an event is received by the state machine.

The Transition dialog always defaults to the "Constraints" tab in which it shows

a) The Guard: an optional condition that must be fulfilled for the transition to ocurr
b) The Action: Any action that should be performed as a reaction to the event provided the guard is met
c) The Trigger (Signal, Change, Call, Time).

Now the Trigger part is fantastic because one can "officially" define input events for that transition. These are all listed in the transition. One can also add (edit from the project browser) a description to the event as this is not possible in the default dialog.

The problem is at it is usually the case you may have multiple events in a single transition as a short notation for cluttering the state diagrams with multiple transitions from the same two states. However, the GUARD condition you specify is shown on the diagram as applying to ALL the events added to the transition. I think the Guard should be individually bound to a trigger rather than to the transition. But then again others might disagree.

Makulik

  • EA User
  • **
  • Posts: 400
  • Karma: +0/-0
    • View Profile
Re: SD: Transition Guard is not bound to a trigger
« Reply #1 on: March 20, 2009, 03:56:10 am »
Hi Emilio,

Seems that mainly UML Spec disagrees about that. The Guard condition is a feature, that is bound to the transition, not to the applicable Events for that transition:

Excerpt from UML Transition specification:
guard: Constraint[0..1]
A guard is a constraint that provides a fine-grained control over the firing of the transition. The guard is evaluated
when an event occurrence is dispatched by the state machine. If the guard is true at that time, the transition may be
enabled; otherwise, it is disabled. Guards should be pure expressions without side effects. Guard expressions with
side effects are ill formed.

I'am afraid you have to use different transitions and split the assigned Events, each with its own guard condition. IMHO it sounds anyway a bit strange for me, to have guard conditions that seem to be more or less dependent on the Events received.

WBR
Günther