🚀 Welcome to MDriven Learn –  MDriven is now on Discord!  Don’t miss the latest Release Notes.
Test OCL constraints and model logic
This page was created by Wikiadmin on 2026-07-29. Last edited by Wikiadmin on 2026-07-29.

Test an OCL class constraint

Object Constraint Language (OCL) is used in MDriven for, among other things, class constraints and derivation rules on derived attributes. OCL expressions are without side effects: they query model data rather than change it. MDriven uses EAL (Extended Action Language), which uses the same syntax as OCL, when data must be changed.

For a class constraint, the OCL expression should evaluate to true. If it evaluates to false, the constraint is broken.

Example: verify that a Car has a Brand

The Bootcamp documentation uses the following constraint on Car:

self.BrandOfCar->notempty

This expression is true when the Car has an associated Brand and false when it does not.

  1. Select Car in MDriven Designer.
  2. In the Property Inspector, find Constraint, select ..., and add a constraint.
  3. Enter self.BrandOfCar->notempty as the OCL expression.
  4. Add a description, such as Cars MUST have a Brand!. The Bootcamp example specifies the constraint type as Warning.
  5. Save the model. The documentation states that MDriven validates OCL expressions on save and shows a red-dot indicator when there is an error.
  6. Open the debugger and inspect a Car with a Brand association in Autoforms.
  7. Remove the Car's Brand association and observe what happens when the object breaks the constraint.

Suggested repeatable check

For each constraint, keep one object state expected to satisfy the rule and one state expected to break it. Record the expression, the object values and associations, and the expected result. Recheck those states after changing the expression or model elements referenced by it.

The sources identify derived attributes as another use of OCL, but do not provide a documented procedure for testing a derived attribute in the debugger. Any derived-value test steps should be added only after they are verified against product documentation or a current MDriven environment.

See also