Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Validation and verification are important activities when working with models. Validation means checking external consistency, i.e. that a model corresponds to what it models (usually the real world), whereas verification means checking internal consistency, i.e. that the model isn't contradicting itself. Validation in Ecore relies on capturing knowledge about a domain in the form of constraints, so that you can check that an actual object structure that conforms to a model, also satisfies additional constraints in the domain.


Suppose you are modelling an organisation with organisational units (OrgUnit), employees (Person) and roles (Role), and you want to capture the fact that people names can only have letters, spaces and dashes (-), and all OrgUnit should have a manager, i.e. an employee with a role labeled 'manager'. The first rule can be checked by hand-editing the setter-method for the name, but it may be better to somehow indicate that a rules is violated, rather than throwing an exception. The second rule can be easily coded, but it is more difficult to ensure the code is always run when relevant object properties are changed, since several objects and properties are involved. A related problem is how to handle step-wise modelling, since the second rule necessarily will be violated while the model is built, it doesn't make sense to consider it an error that should be prevented. Instead, you can check it at a point when you consider yourself done.


Step 1: Add an EAnnotation for using OCL for validation to the EPackage.

Support for using OCL for validation must be explicitly indicated with an EAnnotation on the EPackage. Right-click on the EClass in the editor and add an EAnnotation. Set the source attribute to, and add a key/value pair, with validationDelegate validationDelegates as the key and a language-specific identifier as the value, e.g. for the standard OCL support. If you have installed Acceleo (part of Sirius) and prefer the Acceleo Query Language (AQL) you can use

Step 2: Add an EAnnotation to the appropriate EClass.

This step is the same as step 1 in the previous section: Add an EAnnotation with the source attribute set to anda key/value pair, with constraints as the key and the logical names of the constraints separated by a space.


Step 3: Add an EAnnotation for the constraint expression.

This step links the validationDelegate from step 1 to the constraint in step 2: Add another EAnnotation to the EClass, where the source attribute is the same language identifier as above, i.e. the value for the validationDelegate key of step 1. Then add key/value pairs for each constraint, with the constraint name as the key and the OCL expression for the constraint as the value.

An example is shown in the figure to the right. The OCL expression is executed with an OrgUnit instance as self and computes the set of workers with the role of a manager and checks if its size is 1. It can be a bit tricky to formulate the correct expression, and many language installations provide a custom interpreter view for experimenting. E.g. OCL has a special OCL Console and Sirius has an Interpreter view that support evaluating both OCL and AQL expressions on the current selection in the active editor.