Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Eclipse EMF Validation Framework
Previous Page Home Next Page

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="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.


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire