Constraints

This article was moved to MDriven Wiki Constraints

There are other ways to introduce business rules in the model than using state machines and guards. You can also use constraints. The model already has a lot of implicit constraints from the cardinalities of the association ends. Like if you have cardinality of 1..4 and you have zero objects in that relation – then you have broken constraint.

But you may also define you own constraints:

image

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

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

image

This way have explained at the model level that the domain does not consider it to be ok 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 is Deleted by MDriven – as a result of the Delete operator is executed on the class.

Other things that are checked when the Delete operator is run are the BusinessDeleteRules that exists on all association endpoints:

image

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

The association in the other direct on the other hand

image

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

This entry was posted in MDrivenDesigner, OCL, UML, UMLSchool. Bookmark the permalink.

One Response to Constraints

  1. Pingback: GuardConstraints | CapableObjects

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.