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="https:///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.