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

Add Comment Register



Leave a Reply

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


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>