Constraints are helpful when adding business rules to your application. Constraints are further discussed here.

Guards are what you set on State machine transitions as described here.

GuardConstraints Explained

GuardContraints let you use the Constraints definitions of the class when defining a Guard. In other words, GuardConstraints is a way to avoid the repetition of rules. You may have constraints (rules on the class) and guards (rules on a class for checking the transition of state).

The GuardConstraints for a guard is a way to say that one or many of the constraints work as the implementation of the guard.

This way, rules that must be valid on many transitions can be defined once as a constraint. It is also the best way for users to have insight into why a transition is disabled since Constraints are associated with a message – something that a guard is not.

You associate Constraints with transitions to create a GuardConstraint by right-clicking the transition on the state diagram – choose Edit GuardConstraints…

@Linus; Before version 2015-03-27 was not fully implemented – but now it is.

Above, I add two constraints to the “Thing” class.

If I add a state machine now – with a transition – I can use these constraints as the guard implementation:

Having done this, I get this effect:

The Constraints are shown as a broken red – the Trigger1 is disabled (the guard does this).

When I fix one of the constraints:

The list of errors is reduced, but Trigger1 is not available yet.

And fixing the other constraint enables Trigger1: