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 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. This gives 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 semantics 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 classic code is provided primarily by the following plugins
org.eclipse.ocl
org.eclipse.ocl.ecore
org.eclipse.ocl.uml
The Unified or Pivot metamodel is a prototype for a resolution of a number of fundamental problems with the OCL 2.4 specification. The Pivot metamodel is derived from the UML metamodels for UML and OCL to provide a unified 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 unified merged OCL functionality for the Ecore or UML metamodel instances.
From the specification perspective, the Pivot metamodel
is UML-aligned
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 partially implemented. This allows a clear separation of OCL-semantics.
The unified code is provided by the
org.eclipse.ocl.pivot
with additional optional support for UML in
org.eclipse.ocl.pivot.uml
Additional editing functionality using Xtext is provided by plugins sharing the prefix
org.eclipse.ocl.xtext
Further functionality that remains of exampe qulaity may be fopund in plugins sharing the prefix
org.eclipse.ocl.examples
All APIs in Xtext and Examples plugins are preliminary, as are APIS in classes including ‘internal’ in method, class or package name.
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
Pivot Metamodel
OCL-2.5.oclstdlib library
Pivot Evaluator
Pivot Debugger
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
Classic evaluator
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 (3.2/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 (3.3/4.1) release, the code generator was substantially improved and a number of internal APIs have evolved accordingly. UML support was improved to facilitate usage within Papyrus, and extensibility was improved for use by QVTd.
In the Luna (3.4/5.0) release, further code generation improvements have been made and major new User Interface capabilities added. There is at last an OCL debugger and a Constraint Validity View.
In the Mars (1.0/6.0) release, the transition is nominally complete and the main org.eclipse.ocl.examples.* plugins have been 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. Unfortunately time ran out and so review and revision hads to be truncated. Documentation is sadly deficient.
The Neon (1.1/6.1), Neon++(1.2/6.2), Oxygen (1.3/6.3) and Photon (1.4/6.4) resolve a variety of extensibility issues highlighted by Eclipse QVTd. (The double Neon release was necessiated by SSPI breakage in Xtext 2.9. The Neon release continuing with pre-Xtext 2.9 API, Neon++ migrating.)
Hopefully the future (2.0/7.0) release will track the actual OCL 2.5 submission.
The difficulties of moving from the Ecore/UML-based OCL to the Pivot-based OCL depend on the style of usage.
The OCL Concrete Syntax is the same for both Eclipse OCLs and Pivot-based Xtext tooling has been in use for Ecore-based OCL for a few releases.
The Pivot-based OCL supports a number of new prototype facilities such as null-free collections, template types, map types and lambda types that are not available with the Ecore-based tooling.
The Abstract Syntax models are superficially similar; both have an OCLExpression, however the details are quite different.
The OMG OCL specification requires the AS model to be serializeable in XMI. This is not possible with the current OCL specifications. The intent is partially satisfied for the Ecore/UML-based models using proprietary solutions. The Pivot-based models are fully serializeable and prototype a solution that may be adopted by OCL 2.5.
The Ecore/UML-based models extend the Ecore.ecore/UML.ecore models and so use for instance EStructuralFeature/org.eclipse.uml2.uml.Property as the type of a PropertyCallExp.referredProperty.
The Pivot-based models are UML-aligned and self-contained and so a PropertyCallExp.referredProperty is an org.eclipse.ocl.pivot.Property. Property names are derived from UML but made consistent; ‘many’ properties use a plural name; and 'composed; properties use ‘owned’/‘owning’. Thus UML’s Class.ownedAttribute aligns to Pivot’s Class.ownedProperties.
Since the Pivot-based models have no dependence on an external model, the Pivot Visitors provide an ability to visit all classes, whereas the Ecore/UML-based visitors are partial; Ecore/UML classes must use an EcoreSwitch instead.
The Ecore/UML based models have no support for UML reflection. A form of reflection is available with eClass(), but the result type names are necessarily EClass.
The Pivot-based models support consistent reflection using oclType() which return an ocl.eclipse.ocl.pivot.Class.
The Ecore/UML-based OCL does not use models for additional facilities defined by Complete OCL; an irregular Java API is available.
The Pivot-based approach creates an additional Package for the Complete OCL contributions and behaves as if the complementing Package was merged with the complemented Package.
The Concrete Syntax models are non-normative and have very little commonality.
The Ecore/UML-based models are designed for use with the LPG LALR parser.
The Pivot-based models are designed for use with Xtext and LL ANTLR tooling.
Any user code that uses the CS models is likely to be very tightly coupled to internal APIs and so will need rebuilding and quite possibly updating for each new release.
The complexities of the underlying OCL support are hidden by an OCL Facade, with similar interfaces in all three variants.
org.eclipse.ocl.ecore.OCL
org.eclipse.ocl.uml.OCL
org.eclipse.ocl.pivot.utilities.OCL
Contrasting the deliberately similar examples in
may be instructive.
The Pivot approach is simplified a little by the dual Facade/Handle behavior which ensures that OCL facilities are garbage collected.
While many of the internal classes share similar intents and names between the approaches, the details have evolved as the new approach has learned from its predecessor
long template parameter lists are eliminated
APIs are more strongly typed using e.g. TypedElement rather than String ‘name’ arguments
API compatible extension APIs are folded into a single new API
full auto-generated Visitor hierarchies are exploited
and of course Xtext is far from identical to LPG.
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.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.
Eclipse version numbering policy requires that a major version change occurs when any re-exported component has a major version number change. Consequently when Eclipse UML moved from to UML 2.4 support (4.0.0) and again to UML 2.5 (5.0.0) a corresponding change was forced on the Classic UML support and this is the number that then applies to the whole of Eclipse OCL. However the Ecore dependencies are unchanged and so Ecore dependent releases have advanced more slowly; 3.2 accompanying 4.0 and now 3.5 accompanying 6.0.
This is probably just as confusing for the developers as for consumers. It is however necessary to ensure that the minor changes in the Classic Ecore functionality are not presented as major changes to consumers.
The current OCL version variaously referred to as:
6.0 as the outer version of the OCL master feature
3.5 as the version of the Ecore OCL plugins (compatible with 3.0)
1.0 as the version of the new Pivot OCL plugins