The OCLinEcore Editor editor enables OCL to be embedded in Ecore. This section explains how that OCL is executed.
The Complete OCL editor enables OCL to be provided as a complementing document. This section explains how that complement is installed to become part of the complemented model.
The Interactive OCL console allows you to load OCL and execute OCL expression interactively.
The Java API explains how you can take control of the OCL installation and activation.
The EMF delegate mechanisms and EAnnotations that enable EMF to delegate to OCL to support
-
validation of invariants
-
execution of operation bodies
-
evaluation of property initial and derived values
are described in the Delegates section of the Programmers Guide.
Eclipse OCL supports the production of custom messages by defining a String-valued message expression as a parenthesized clause on an invariant.
An OCL invariant is an expression that returns a true or false value.
In Juno and Kepler, Eclipse OCL supported an extension whereby a null return indicated an ‘error’ rather than a ‘warning’, and an invalid return was ‘fatal’.
Luna supports a rich-invariant idiom whereby an invariant can compute a tuple of results, only one of which is actually returned by tooling that does not understand the idiom. Rather than
invariant InvariantName:
boolean-valued-invariant-expression;
You can code additional information by recoding
ocl-status-expression
as
invariant InvariantName:
Tuple{
status=boolean-valued-invariant-expression,
message=string-valued-message-expression,
severity=integer-valued-severity-expression, -- -ve error,0 ok,+ve warn
... -- more custom fields as desired
}.status;
The idiom is a little verbose, but compatible with all OCL tooling. Eclipse OCL provides some editor enhancements to make the usage more acceptable.
In the OCLinEcoreTutorial Example there is an alternative syntax for custom messages.
invariant SufficientCopies:
library.loans->select((book = self))->size() <= copies;
may be changed to
invariant SufficientCopies('There are '
+ library.loans->select((book = self))->size().toString()
+ ' loans for the ' + copies.toString() + ' copies of \'' + name + '\''):
library.loans->select((book = self))->size() <= copies;
to replace the default diagnostic:
The 'SufficientCopies' constraint is violated on 'Book b2'.
by
There are 3 loans for the 2 copies of 'b2'.
Unfortunately, in the Photon release, EMF does not support this customization. This must be activated explicitly using an EValidator that is aware of the ValidationDelegateExtension extended API. This is available by using the OCLinEcoreEObjectValidator.
Integration of Complete OCL documents is harder because Complete OCL complements pre-existing models. These cannot always be aware of the existence of that complement, since the author of a model cannot know what complements may be added by its users.
The complete model formed from the primary models and the OCL complements is application-specific and so applications must gather the contributions together. Prior to the Indigo release, this restricted Complete OCL usage to Java applications that could gather the complements.
The CompleteOCLEObjectValidator may be used to install a Complete OCL document.
In many editors an OCL->Load Document is available in the context menu to facilitate loading a complementary Complete OCL document.
You may drag and drop one or more files from within Eclipse or outside Eclipse into the dialog, or use one of the browser buttons to locate a Complete OCL document.
The org.eclipse.ocl.xtext.completeocl.complete_ocl_registry may be used to register Complete OCL files against the nsURIs that they complement. These extension points may be defined in plugins or projects. In either case clicking Browse Registered OCL Files... presents a list of registered Complete OCL documents applicable to the context from which the dialog was invoked.
The Browse File System... button present a file system explorer so that a Complete OCL document file can found anywhere.
If you want to use OCLinEcore as a validation language for Xtext you must:
Use a manually maintained Ecore model to define your parsed grammar model, otherwise your embedded OCL will be lost each time you regenerate the editor. For non-trivial models, switching from auto-generated to manual maintenance is a good idea, since you may need to control changes carefully to maintain upward compatibility for existing models.
Modify the Validator class generated by genmodel to extend OCLinEcoreEObjectValidator rather than EObjectValidator. See OCLinEcoreEObjectValidator for details.
If you want to use Complete OCL as a validation language for Xtext, you may use the CompleteOCLEObjectValidator to register the Complete OCL for EMF Validation. This may readily be achieved by reusing the empty example JavaValidator created by Xtext to install the Complete OCL. If your Xtext language is States, and your Complete OCL is model/States.ocl in StatesProject you should change your StatesJavaValidator to:
public class StatesJavaValidator extends AbstractStatesJavaValidator
{
@Override
public void register(EValidatorRegistrar registrar) {
super.register(registrar);
StatesPackage ePackage = StatesPackage.eINSTANCE;
URI oclURI = URI.createPlatformResourceURI(
"/StatesProject/model/States.ocl", true);
registrar.register(ePackage,
new CompleteOCLEObjectValidator(ePackage, oclURI));
}
}