# Using OCL

Out of the box, the EMF Validation Framework provides support for two constraint languages: Java and OCL. As we have seen in another topic, Java constraints register the name of a class extending the AbstractModelConstraint class. For constraints specified in OCL, there is no code required.

The org.eclipse.emf.validation.ocl feature provides an OCL language that allows static constraint providers to specify OCL constraints directly in the OCL. Moreover, because this OCL capabilitiy is contributed as a language provider, any dynamic constraint provider that delegates constraint creation to the AbstractModelConstraintProvider class can also specify its constraints in OCL by providing IConstraintDescriptors with OCL as the language and the expression as the body. Indeed, this structure is illustrated in an example static provider:

    <extension point="org.eclipse.emf.validation.constraintProviders">
      <category name="Library Constraints" id="com.example.library">

      <constraintProvider>
        <package namespaceUri="http:///org/eclipse/emf/examples/library/extlibrary.ecore/1.0.0"/>
        <constraints categories="com.example.library">
          <constraint
                lang="OCL"
                severity="WARNING"
                mode="Live"
                name="Library Must have a Unique Name"
                id="com.example.library.LibraryNameIsUnique"
                statusCode="1">
            <description>Libraries have unique names.</description>
            <message>{0} has the same name as another library.</message>
            <target class="Library">
                <event name="Set">
                     <feature name="name"/>
                </event>
            </target">

            <![CDATA[
            Library.allInstances()->forAll(l |
                l <> self implies l.name <> self.name)
            ]]>

          </constraint>
        </constraints>
      </constraintProvider>
    </extension>

This looks very much like the Java example of a static constraint provider, except for the language specification and the element body content in place of a Java class name. Here, we use a CDATA section to simplify working with the angle brackets in the OCL expression.

The OCL language provider supports a {0} parameter in the message. It is replaced by the validation target element.

This works well for simple constraints that require only the MDT OCL component's Ecore parsing environment, without any customizations such as global variables. For applications that have such requirements, the OCL feature provides an AbstractOCLModelConstraint class that can be extended by a custom OCL constraint implementation. See the Constraint Languages topic for details of how to plug in alternative factories for constraints, keyed by the language.

Copyright (c) 2000, 2007 IBM Corporation and others. All Rights Reserved.