MDT/OCL Limitations

Limitations

The Ecore and UML binding have evolved with OCL from 1.x to 2.0, 2.2 and 2.3. They have a substantial legacy usage that is difficult to change, so as problems with OCL 2.3 are identified, it is not clear whether they can be fixed for existing clients.

The new Pivot binding prototypes solutions to many problems and so may be considered a candidate for OCL 2.5.

This page identifies the differences between the Ecore (and UML) bindings and the Pivot binding and where appropriate significant Bugzillas that have been WONTFIXed in regard to the Ecore binding and the OCL 2.3 specification.

Facility	Bugzillas	Commentary
Operation Lookup	339952	OCL 2.3 does not specify use of inherited operations. The Ecore binding uses a local operation in preference to an inherited operation. The Pivot binding selects the best static match of all inherited operations for subsequent dynamic dispatch.
Operation Dispatch	367822	OCL 2.3 does not specify dynamic dispatch of operations. The Ecore binding invokes the static operation regardless of overriding. The Pivot binding selects the dynamic overload.
Iteration Reference		OCL 2.3's AST references iterations by name. Iterations are therefore unmodeled in the Ecore binding. The Pivot binding introduces a library model allowing iterations to be referenced by e.g. IterationExp.referredIteration.
Complementary Feature Reference		OCL 2.3 does not specify how a feature defined in a Complete OCL document is modeled for reference within the AST. They cannot be referenced in an Ecore binding XMI serialization. The Pivot binding creates a complementary model that is logically merged; complementary features are referenceable.
Type references		OCL 2.3 does not specify how external models are introduced into the OCL expression environment. The Ecore binding is unable to reference external models in expressions such as oclIsKindOf(SomeType). The Pivot binding introduces a URI form of qualification allowing oclIsKindOf(_'http:/...'::SomeType).
Model references		OCL 2.3 does not specify how external models are introduced into an OCL document. The Ecore binding therefore relies on either Java API or the OCL Model Registry to provide the missing context. The Pivot binding introduces an 'import' and a 'library' syntax to specify external models.
Value Equality		OCL 2.3 specifies equality based on object identity; no OCL implementation respects this aspect of the specification since values must clearly be equal based on value not object identity. The Ecore binding uses Java objects and so treats real and integer values as distinct. The Pivot binding uses value equality for data types and so real and integer values may be equal and Sets containing a mix of integer and real values do not have duplicate numeric values.
Value polymorphism		OCL 2.3 specifies a very incomplete hierarchy of polymorphic Value classes; OCL 2.3 does not require implementations to use them. The Ecore binding ignores this aspect of the specification and uses Java classes and collections directly; the Ecore binding has some subtle malfunctions on deep collection operations where equality is inconsistent. The Pivot binding implements a consistent polymorphic hierarchy of Value classes resulting in semantic consistency and extensibility.
Numeric accuracy		OCL 2.3 specifies unlimited numeric precision. The Ecore binding ignores this aspect of the specification and uses Java's Integer and Double; the code has evolved to have significant support for Long and some tolerance of BigDecimal, BigInteger, Float and Short. The Pivot binding implements a consistent polymorphic hierarchy of Value classes with alternate Integer/Long/BigInteger equivalents that grow as necessary.
Reflection		OCL 2.3 specifies oclType() with very restricted inconsistent capability. The Ecore binding does not implement oclType(); EObject::eClass() can be used to similar effect but with incorrect spelling of UML meta-class names. The Pivot binding implements a fully reflective oclType() so that OCL expressions can navigate the meta-model using 'UML' names.
UML alignment		The OCL 2.3 specification of UML-alignment is aspirational; some parts are actually aligned to UML 1.x. The Ecore binding deviates from UML alignment by using Ecore as its meta-model. The Pivot binding uses a Pivot meta-model that merges UML and OCL classes.
Library Model		OCL 2.3 specifies the OCL Standard Library without a model. The Ecore binding provides a partial model accompanied by bespoke Java code. The Pivot binding provides a modeled library, and an associated editor; the library model can be replaced or extended.
Templates		The Pivot binding Library Model uses UML template types to model Collections and UML template operations to model operations such as Collection::product.
Lambda Types		The Pivot binding Library Model uses Lambda Types to model the body of an iteration.
Type Constructors		The Pivot binding Library Model introduces a Tuple-like syntax to create immutable Class and DataType instances.