Versions Compared

Key

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

...

Step 1: Add an EAnnotation to the appropriate EClass.

Right-click on the EClass in the editor and add an EAnnotation. Set the source attribute to http://www.eclipse.org/emf/2002/Ecore. Then add a key/value pair, with constraints as the key and the logical name of the constraint (a valid Java name) as the value. If you need to add several constraints, separate their names by a space.

Step 2: Generate code and locate the validation method stub(s)

Genmodel will generate an EValidator subclass in the util package with one method for each constraints (if there are any) named validator_<constraint name>. The method body contains template code for adding a diagnostic for a violated constraint with ERROR severity. The condition is initially false and needs to be replaced by the real constraint logic. An example of the generated stub is shown right.

 

Step 3: Implement the constraint logic in Java

The false condition has been replaced by a call to the hasOnlyNameCharacters helper method. You may also lower the severity if the constraint is more of a suggestion. Notice how NOT is added after @generated, to indicate that we've change generated code. This will prevent the code from being overwritten if the class is regenerated.

Code Block
	/**
	 * Validates the nameCharacters constraint of '<em>Person</em>'.
	 * <!-- begin-user-doc -->
	 * <!-- end-user-doc -->
	 * @generated NOT
	 */

	public boolean validatePerson_nameCharacters(Person person, ...) {
		if (! hasOnlyNameCharacters(person.getName())) {
			if (diagnostics != null) {
				...
			}
			return false;
		}
		return true;
	}

	private boolean hasOnlyNameCharacters(String name) {
		for (int i = 0; i < name.length(); i++) {
			char c = name.charAt(i);
			if (! (Character.isLetter(c) || c == ' ' || c == '-')) {
				return false;
			}
		}
		return true;
	}

Step 4: Make the implementation available for the editor

Since the constraint logic is implemented in Java code that must be compiled, you need to either launch another Eclipse or install the EMF project in the same Eclipse, to make the constraint available in an editor.

 

 

Interpreted constraints

As an alternative to Java code that must be compiled, you can use an interpreted expression language like OCL for coding constraints. The advantage is a shorter development cycle, the downside is slightly more complex configuration. And of course, there are both advantages and disadvantages to expression languages. Note that the available expression languages depend on what plugins are installed in Eclipse. E.g. OCL support is not part of the standard modelling package, so must be installed, but luckily it is available in the standard Eclipse update site, so it's easy to install.

...

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 http://www.eclipse.org/emf/2002/Ecore, and add a key/value pair, with validationDelegate as the key and a language-specific identifier as the value, e.g. http://www.eclipse.org/emf/2002/Ecore/OCL as the value.

Step 2: Add an EAnnotation to the appropriate

for the standard OCL support. Other identifiers are

 

http://www.eclipse.org/acceleo/query/1.0


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 http://www.eclipse.org/emf/2002/Ecore 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 http://www.eclipse.org/emf/2002/Ecore/OCL, 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 OCL expressions on the current selection in the active editor.