You can use this three-part example series to learn how to write and test OCL expressions against a small evolving model in MDriven Designer.
Object Constraint Language (OCL) is MDriven's declarative query and rule language. Use it when you want to describe a result, constraint, derivation, or condition without changing data. For example, an OCL expression can select the fruit that meets a condition or calculate a value derived from the fruit in a bowl.
This series starts with a simple FruitBowl model and then changes the requirements to support FruitSalad, including fractions of fruit. The progression demonstrates an important modeling practice: revisit expressions when the meaning and structure of the model change.
What you will learn
| Part | Focus | What you can practice |
|---|---|---|
| Part 1: OCL Common Expressions | Build and evaluate common OCL expressions in a small model. | Query objects and inspect the result while you model. |
| Part 2: OCL Operators | Use operators, association navigation, and derivation in the FruitBowl example. | Navigate from one object to related objects and apply an operator to the resulting collection. |
| Part 3: Derivation properties | Adapt derivations after the requirement changes from whole fruit in a bowl to FruitSalad with fractions. | Review whether a derived value still represents the intended business meaning when quantities become fractional. |
Follow the example series
- Start with Part 1. Create or open the small example model and use the OCL editor to enter expressions.
- Evaluate expressions against example data in the MDriven debugger. Inspect the returned objects or values before placing an expression in a derivation, constraint, or ViewModel.
- Continue with Part 2 to practice operators and navigation. Focus on what each intermediate collection contains.
- Continue with Part 3. Treat the FruitSalad requirement as a model change: check the type and meaning of each quantity, then update derivation expressions to match.
- When an expression does not return the expected result, reduce it to one navigation or operator at a time, inspect that result in the debugger, and then add the next operation.
Read expressions as a sequence of results
OCL often starts with a set of objects and then applies operations to that set. For example, the following patterns from a vehicle model illustrate how to reason about an expression:
Car.allinstances->size
This asks for all instances of Car and then returns the number of cars. If there are four cars, the result is 4.
Car.allinstances->first
This returns the first object from the retrieved collection. Replace first with last to return the last object.
Car.allinstances->select(oneCar | ...)
select keeps the objects for which its Boolean condition is true. oneCar is the loop variable: it names the car currently being tested. In the FruitBowl example, use the same pattern to name the fruit or bowl object being evaluated.
You can also combine collection operations. For example, order a collection before taking a subsequence when you need a predictable subset. Inspect the collection after each operation; the debugger makes it easier to see whether ordering, filtering, or navigation produced the intended objects.
For operator details and additional examples, see Documentation:OCLOperators and Documentation:Turnkey session 7: Expressions.
Apply OCL in the model
MDriven uses OCL in several model and user-interface contexts. The same expression style can describe a class constraint, a derived attribute, a derived association, a ViewModel column or nesting definition, a ViewModel visibility or enabled state, style information, object presentation, an action-enable expression, or a state-machine guard.
For example, a derived attribute can use an OCL expression to calculate a value from related objects. A ViewModel can use OCL to determine which objects appear in a list. The expression must describe a result and must not modify the data being queried.
OCL does not change data
OCL expressions must have no side effects. That means evaluating an OCL expression is not expected to create, delete, or update objects. If your requirement is to change data, use EAL (Extended Action Language), which uses OCL-like syntax for actions.
This distinction matters when working through the FruitBowl and FruitSalad examples: use OCL to calculate or validate the composition of a bowl or salad; use EAL only when the task is to modify that composition.
When requirements change
The third part of the series changes the domain from FruitBowl to FruitSalad and introduces fractions of fruit. Use this change as a review checklist for every affected expression:
- Confirm which class now owns the relevant information.
- Confirm whether the expression returns an object, a collection, a Boolean value, or a numeric value.
- Check whether a derivation based on whole items still gives the correct result when a quantity can be fractional.
- Evaluate the expression with representative test data in the debugger.
- Update constraints, derivations, and ViewModel expressions that rely on the old meaning.
For example, an expression that only counts fruit objects answers a different question from an expression that derives a total based on fractional quantities. The correct expression depends on the business meaning that the changed model represents.
Continue learning
Use this series as a practical companion to the conceptual OCL documentation. Read Documentation:OCL Expressions for where OCL is used in MDriven and Documentation:Learn OCL for the wider language overview. Use Documentation:OCL to browse operator, collection, numeric, string, date/time, and conditional-expression topics.