3

In the design of UML state charts it appears that I can chose to use either triggers or guard logic to achieve transitions between states.

So which is better to use? Given the same logic for transition, does a trigger behave any differently than a guard? What are the benefits/drawbacks of one over the other?

Are there perhaps differences depending on the particular tool, or does the UML standard strictly define the behaviors of either method of transition?

I'm presently using Simulink Stateflow to design a state machine.

docscience
  • 145
  • 6

2 Answers2

3

Those two are different concepts.

Trigger is an event occurrence which enables the transition, while guard is a condition that must be evaluated to true in order for the transition to proceed.

So you cannot use them interchangeably — they have different roles.

Also note that the default guard (if none is specified) is [true], so the trigger is often sufficient to move from one state to another.

Update:

Summary:

  • Trigger (event) is some new data (of any data type) that was received by the object.
  • Guard is boolean expression on some data that is alrady present in the object.

enter image description here

Trigger (event) is an outside event that some other actor fired - user has pressed a button, browser requested a page load, etc. So in the image above, every time user presses a digit on a digital lock it fires "pressed digit" event.

If the pin (sequence of digits) is valid, then the transition to unlocked state will be enabled.

Yet another way to look at it:

If you press a keyboard key the system fires a keypress event, that would be a trigger whose value is the pressed key. Then you can make a guard [pressedKey = enter] (guard is always a boolean expression).

However having just the guard is not enough here, because there would be nothing to compare against.

Peter Uhnak
  • 9,617
  • 5
  • 38
  • 51
  • I'm just seeing names and terminology, but in the end the action or result seems to be the same, not different using either a guard or trigger. If I put the expression $x$ in the guard and drive it true or false with the same data, logic, event , or whatever name you want to give it, this gives me the same result as driving a trigger with the same. The transition either happens or doesn't happen. It's still not clear why one. – docscience May 01 '15 at 20:08
  • vs the other might be different. Can you offer a more specific example that might illustrate the difference in terms of outcome or action? – docscience May 01 '15 at 20:09
  • @docscience I updated the answer, it is perhaps more clear now. – Peter Uhnak May 01 '15 at 20:55
  • 1
    A trigger is what determines whether a transition is attempted, a guard will then determine whether the transition can be taken. A transition will never be taken if there is no event to trigger it. The guard for the transition is only evaluated if the event (trigger) indicates that the transition can be taken. – CharlesRivet May 02 '15 at 18:53
  • I played around a bit with similar state charts, one that used only guards and input data to control transitions, and the other only triggers to control the transitions. With guards I always get predictable transition between the states. With triggers I get transitions - sometimes. But the triggers are very unpredictable. It's like the chart doesn't always see them. One difference is that triggers require specifying rising edge, falling edge, both or function call. I've been using rising edge. I guess I'm still not understanding triggers. – docscience May 02 '15 at 18:57
1

Strictly speaking, guards cannot be used without triggers.

UML 2.5.1 specification (Section 14.2.4.8, page 331) defines State Machine's transitions by the following BNF expression: 

[<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]

While UML 2.0 defined them as:

<transition> ::= <trigger> [‘,’ <trigger>]* [‘[‘ <guard-constraint>’]’] [‘/’ <activity-expression>]

Triggers are defined as:

<trigger> ::= <call-event> | <signal-event> | <any-receive-event> | <time-event> | <change-event>

So, in both cases, there cannot be a transition with a guard that doesn't have any trigger.

The only exception, according to UML 2.5.1, are internal transitions, which are specified by:

{<trigger>}* ['[' <guard>']'] [/<behavior-expression>]
Andriy Makukha
  • 7,580
  • 1
  • 38
  • 49