Constraints is a good way to add business rules to your application. Constraints are further discussed here.
Guards are what you set on State machine transitions as described here.
This article is on GuardConstraints.
GuardContraints lets you use the Constraints definitions of the class when defining a Guard. In other words GuardConstraints is a way to avoid repetition of rules. You may have constraints (rules on the class) – and you may have guards(rules on a class for checking 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 to let user have insights 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; Prior to versions 2015-03-27 this was not fully implemented – but now it is.
Above I add two constraints to the “Thing” class.
If I now add a state machine – with a transition – I can use these constraints as the guard implementation:
Having done this I get this effect:
The Constraints show up as 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 makes the Trigger1 enabled: