EMF provides three delegation mechanisms that enable functionality not directly supported by EMF to be delegated to a technology that can support it.
a Validation Delegate supports checking additional invariants on an EClassifier
a Setting Delegate supports getting an initial or derived computed value for an EStructuralFeature
an Invocation Delegate supports the execution of a function defined by an EOperation
and also
a Query Delegate supports the execution of a function not defined by an EOperation
When you use the OCLinEcore editor, the required EAnnotations to support delegation are provided automatically. This section provides sufficient detail to allow them to be maintained manually using the Sample Ecore Editor or Java code.
These EAnnotations ensure that delegates can be used for both genmodeled and reflective models. The use of genmodel to generate Java classes for your metamodel has significant performance benefits for modeling, but currently makes little difference for OCL execution. The use of genmodel has the disadvantage that you must install the Java classes and so the user of the Java classes must run in a different Eclipse or standalone session to the developer. Conversely, using reflective models allows both developer and user to share the same Eclipse session.
There is one GenModel setting that needs to be correctly set to ensure that OCL within generated Java classes can successfully be invoked by itself. Make sure that support for reflective operation invocation is generated by setting the
Operation Reflection option to
true.
Each application implementing delegation has an associated Delegate URI, which is
http://www.eclipse.org/emf/2002/Ecore/OCL for the classic evaluator
http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot for the Pivot evaluator
Only the
http://www.eclipse.org/emf/2002/Ecore/OCL was available in the Helios release and so the Helios release of the OCLinEcore editor used that URI.
The OCLinEcore editor uses the Pivot metamodel which is more accurate and OMG compliant and so in the Indigo release, the OCLinEcore editor uses the
http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot URI and converts all incoming usage of
http://www.eclipse.org/emf/2002/Ecore/OCL URI to
http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot.
As described in The two Eclipse OCLs the Pivot evaluator uses an intermediate Pivot model to hide Ecore and UML2 and so allow full OMG-compliance. The Pivot evaluator is only available when the OCL Examples and Editors feature has been installed as described in Installation.
The OCL Delegate URIs are registered using the
org.eclipse.emf.ecore.invocation_delegate
org.eclipse.emf.ecore.setting_delegate
org.eclipse.emf.ecore.query_delegate
org.eclipse.emf.ecore.validation_delegate
extension points.
The initialization code for standalone usage of EMF delegates is given in the Standalone section.
An invocation delegate is invoked to execute the body of an EOperation. An invocation delegate must be registered for the EPackage of the EClassifier of the EOperation.
The EPackage registration is provided by an EAnnotation on the EPackage
source =
http://www.eclipse.org/emf/2002/Ecore
key =
invocationDelegates
value =
OCL-Delegate-URI
The invocation delegate is provided by an EAnnotation on the EOperation
source =
OCL-Delegate-URI
key =
body
value =
OCL-expression
The
OCL-expression
is evaluated to provide the EOperation value with the containing EClassifier as the
self context object and the EParameters accessible as parameters from OCL. The return type of the
OCL-expression
must conform to the return type of the EOperation.
A setting delegate is invoked to provide the initial or derived value of an EStructuralFeature. A setting delegate must be been registered for the EPackage of the EClassifier of the EStructuralFeature.
The EPackage registration is provided by an EAnnotation on the EPackage
source =
http://www.eclipse.org/emf/2002/Ecore
key =
settingDelegates
value =
OCL-Delegate-URI
The setting delegate is provided by an EAnnotation on the EStructuralFeature
source =
OCL-Delegate-URI
key =
derivation
value =
OCL-expression
The
OCL-expression
is evaluated to provide the EStructuralFeature value with the containing EClassifier as the
self context object. The result type of the
OCL-expression
must conform to the type of the EStructuralFeature.
An
initial rather than
derivation value may be specified. The
initial is ignored if a
derivation is also specified.
A validation delegate is invoked to provide additional validation of an EClassifier. A validation delegate must be registered for the EPackage of the EClassifier for which the EClassifier provides any Ecore invariants or Ecore constraints. Both Ecore constraints and invariants constrain an EClassifier, the difference is that an Ecore invariant is realised by an EOperation and so an Ecore invariant may be re-used by modeling environments that may wish to selectively check or re-check constraints.
The EPackage registration is provided by an EAnnotation on the EPackage
source =
http://www.eclipse.org/emf/2002/Ecore
key =
validationDelegates
value =
OCL-Delegate-URI
All Ecore constraints must be listed in an EAnnotation on the EClassifier
source =
http://www.eclipse.org/emf/2002/Ecore
key =
constraints
value =
constraintName1 constraintName2 constraintName3
The validation delegate for each Ecore constraint is provided by a further EAnnotation on the EClassifier
source =
OCL-Delegate-URI
key =
constraintName
value =
OCL-expression
The validation delegate for each Ecore invariant is provided by an EAnnotation on the EOperation
source =
OCL-Delegate-URI
key =
body
value =
OCL-expression
The
OCL-expression
is evaluated to validate the EClassifier with the EClassifier as the
self context object. The result type of the
OCL-expression
must be Boolean.
When a validation fails EMF generates a default diagnostic of the form
The
'constraintName'
is violated on
'constrainedObject'
.
If the OCLinEcoreEObjectValidator or CompleteOCLEObjectValidator are used a custom message may be supplied using an additional EAnnotation on the EClassifier.
source =
OCL-Delegate-URI
key =
constraintName
$message
value =
OCL-expression
The
OCL-expression
is evaluated to produce the custom message with the EClassifier as the
self context object. The result type of the
OCL-expression
must be String.
The severity of the diagnostic can also be customized by exploiting the four values of the Boolean value of the constraint evaluation.
true indicates successful validation
false indicates unsuccessful validation with warning severity
null indicates unsuccessful validation with error severity
invalid indicates a failure to perform validation (error severity)
A query delegate is invoked to evaluate a parameterized query on a EObject for which there is no corresponding EOperation. A query delegate is registered to install this query and allow its compiled form to be cached. The delegate may then be invoked as many times as required for compatible context objects and parameters.
This facility enables an EMF application to execute OCL without declaring or instantiating any OCL classes.
The query delegate registration is analogous to direct use of
OCL.newInstance().createHelper().createQuery()
The query delegate execution is analogous to
OCL.evaluate()