There are other ways to introduce business rules in the model than using state machines and guards. You can use constraints.

The model already has a lot of implicit constraints from the cardinalities of the association ends. If you have cardinality 1..4 and you have zero objects in that relation – then you have broken constraint.

Define constraints

You may also define your own constraints:

You can choose if a broken constraint (a constraint that evaluates to false) should be treated as Information, Warning, or an Error to the user.

Delete constraints

You can also define the constraint as being a delete constraint only:

This way, you have explained at the model level that the domain does not consider it to be acceptable to delete a Car-object as long as we have the deposit unless it is in state Scrapped.

The delete constraints will be checked when Deleted by MDriven – as a result, the Delete operator is executed on the class.

Other things that are checked when the Delete operator is run are the Business Delete Rules that exist on all association endpoints:

We as modelers should decide the best rule for each association end. In this case, is it acceptable to delete a Brand if Cars are left in the AllCarsOfThisBrand association? No, I think not. I am setting it to “MustBeEmpty.”

The association is in the other direct on the other hand.

I set that to “NeedNotBeEmptyNoWarning” – because deleting a car object is okay even if it has a brand.

Constraints evaluation in OCL

If you want to evaluate constraints in OCL, use OCLOperators constraints for example.

Usage of constraints

Constraints automatically show up in ViewModels - but you may opt them out on a per-ViewModel level:

You can also access Constraints and their "brokenness" via OCL Operators brokenConstraints and Constraints:

See also: OCLOperators_constraints