The core functionality of OCL that supports expressions over models is called the Essential OCL. This language is of very limited use by itself since there is no way in which the models can be provided. Essential OCL is therefore extended in various ways to provide this missing context.
The Complete OCL provides a language for a document in which OCL complements an existing meta-model with invariants, and additional features.
OCLinEcore embeds OCL within the annotations of an Ecore model to enrich that model.
UML supports the use of OCL constraints as a form of OpaqueExpression, and UML tools such as Papyrus support those constraints for UML models.
The Eclipse OCL project provides four OCL languages to support these usages.
Essential OCL provides the core extensible capability of specifying expressions for models.
Complete OCL provides the ability to use OCL in a self-standing document to complement an existing meta-model with invariants, and additional features.
OCLinEcore enables OCL to be embedded within an Ecore meta-model to add invariants for classifiers, bodies for operations and computed values for properties.
OCLstdlib supports the definition of the standard and custom OCL Standard Libraries.
The Eclipse OCL project is making a transition to a new underlying infrastructure.
The classic code base emphasized utility for Java programmers. It originally supported Ecore meta-models and evolved to support UML as well. An OCL Console was added to support interactive experimentation with OCL expressions.
Interactions with the MMT/QVTd project resulted in a refactoring of the grammars so that they could be extended for use by QVT. At the same time the grammars were migrated to use LPG 2.
The dual support for Ecore and UML was achieved by a shared generic meta-model in which the distinctions between Ecore and UML meta-models were accommodated by substantial (often ten parameter) template parameters lists. Sometimes these lists are hidden by derived bindings, but sometimes the full lists are exposed making for rather cumbersome Java code for the OCL developers and OCL consumers alike.
The classic evaluator is tightly coupled to Ecore which might appear efficient, but the lack of separation of OCL-specification semantics from Java-implementation seamntics makes accurate implementation of equality in nested collections hard to achieve.
The classic code endeavored to comply with OCL specification despite significant ambiguities in the specification, but since the classic code evolved from an OCL 1.x compliance and Ecore utility there are a number of areas where accurate OMG compliance is hard to achieve.
The Pivot metamodel is a prototype for a resolution of a number of fundamental problems with the OCL 2.3.1 specification. The Pivot metamodel is derived from the UML metamodels for UML and OCL to provide a coherent metamodel for UML with executable semantics.
In practice, when using the Pivot metamodel for Ecore or UML metamodels, a Pivot metamodel instance is created on the fly to provide the coherent merged OCL functionality for the Ecore or UML metamodel instances.
From the specification perspective, the Pivot metamodel
supports modeling of the OCL standard library
supports ‘merging’ of additional Complete OCL definitions
supports an interchangeable XMI representation
supports a fully reflective oclType()
From the Eclipse perspective, the Pivot metamodel
hides Ecore differences with respect to EMOF
hides MDT/UML2 differences with respect to UML
allows much of the semantics to be defined by a single library model
allows user extension and replacement of the library model
allows for exact OMG compliance
At the same time, the Values package that forms part of the specification has been implemented. This allows a clear separation of OCL-semantics, and although the extra object apparently wrapping each value might appear to incur overheads, we expect to streamline this so that the new structure is accurate and faster.
This transition started in the Helios (3.0) release for which Xtext editors were provided for OCLinEcore, Complete OCL and the OCL Standard Library. There was then no Pivot meta-model and so the editors offered only syntactic validation. It was not possible to persist an AST as XMI or to evaluate code that had been parsed by the Xtext parsers. It was necessary to re-parse with the LPG parsers.
In the Indigo (3.1) release, the Pivot metamodel prototype was introduced and used to support semantic validation within the Xtext editors. The OCL Standard Library was realised using the Pivot metamodel and a new highly extensible evaluator was implemented. These facilities are used by the new OCL Xtext Console.
Therefore when using the OCL Xtext Console the contributing tools are
Essential OCL Xtext editor
When using the classic OCL Console the contributing tools are
LPG parser and hand-coded Syntax Helper
Ecore (or UML) metamodel bindings
Hand coded library implementation
Since these tools are different there may be occasions where the increased OMG compliance of the Pivot metamodel gives different behavior to the classic metamodels.
In the Juno (4.0) release, there is a preliminary Java code generator for the Pivot metamodel so that all the parsing overheads and significant parts of the execution overheads of OCL embedded in Ecore models occurs at genmodel time rather than during execution.
In the Kepler (4.1) release, the code generator has been substantially improved and a number of internal APIs have evolved accordingly. UML support has been improved to facilitate usage within Papyrus, and extensibility has been improved for use by QVTd.
In the Luna (4.2) release, the transition should be complete and many org.eclipse.ocl.examples.* plugins will be renamed to org.eclipse.ocl.*. All functionality should use the new Pivot metamodel by default. However the classic Ecore and UML support will remain for compatibility.
Eclipse OCL has two different styles of APIs
The major tool APIs originally provided by the org.eclipse.ocl.OCL class have evolved only slightly to org.eclipse.ocl.ecore.OCL and org.eclipse.ocl.uml.OCL for the classic metamodels and org.eclipse.ocl.examples.pivot.OCL for the Pivot metamodel.
These APIs support the use of OCL as a tool to parse and evaluate constraints and queries.
These APIs will change very little; just the package changes according to the chosen metamodel representation.
The internal parsing APIs were made public in 1.3.0 to support parser extension by QVT. These APIs are very tightly coupled to a particular LPG implementation of a particular OCL grammar formulation. It is extremely difficult to replicate these APIs for the ANTLR grammar that underlies the Xtext editors. It is also doubtful whether these APIs can be preserved as the OCL specification is clarified to more clearly specify what words are reserved and what is extensible.
It is therefore unlikely that the internal APIs for the classic metamodels will be replicated for the Pivot metamodel. However since an LPG grammar is significantly (ten-times) smaller and perhaps a bit faster (two-times) it is planned to provide an automated Xtext to LPG translation so that a smaller LPG grammar can populate the same auto-generated Concrete Syntax structures as the ANTLR grammar.
This functionality is intended to form part of a new grammar extension API that will enable OCL-extending languages such as QVT to re-use and extend not only the grammar but also all the semantic scope resolution and concrete to abstract syntax mappings.