OCL/Pivot Model

The Pivot Meta-Model is the key to an integrated fully OMG-compliant implementation in the MDT/OCL 4.X architecture. The usage of the Pivot Meta-Model is shown in

The diagram is similar to a UML Object Diagram in which boxes denote named instances of underlined classes. However in this diagram each box denotes a named model with all its constituent model element instances of corresponding meta-model elements.

The simple is-a arrows indicate that the relevant source meta-model elements generalise related target meta-model elements.

The block arrows denote run-time information flow to maintain equivalence of one meta-model with another.

Use Cases

Traditional Ecore or UML modeling

A traditional Eclipse Ecore or Eclipse UML user makes use of their instance of an Eclipse-Ecore-MM or Eclipse-UML-MM in traditional fashion. This usage is denoted as using the Eclipse UML or Eclipse Ecore APIs and requires no co-ordination between disparate meta-models.

MOF-compliant modeling

Ecore is slightly different to EMOF and consequently Eclipse UML is slightly different to OMG UML. This can be very awkward when struct MOF-compliance is necessary.

MOF-compliance is supported by adapting the traditional Ecore or UML meta-model with either an Eclipse-UML-Pivot-MM or an Eclipse-Ecore-Pivot-MM. Each of these adapted meta-models generalise the Pivot-Meta-Model that is as compliant as possible with the MOF and UML standards. This compliance extends to reflection and so the getMetaClass() operation will return a Pivot Meta Model instance rather an Ecore Meta Modekl Instance.

The planned implementation of the adapters will use Ecore Adapters so that any changes using, for instance the Eclipse Ecore API, will be visible via the MOF Pivot API and vice-versa.

Dynamic UML

Ecore supports creation of dynamic instance models by invoking Create Dynamic Instnace in the Sample Ecore Editor. This dynamic instance may then be editoed in the Sample Reflective Ecore Editor.

There is no counterpart for UML, which requires that the UML meta-model is manually exported to Ecore in order to use Ecore code generation or dynamic instantiation. This manual export must be repeated for each change.

The master/slave relationship between Pivot Meta-Models should make this transparent. When a slave Eclipse-Ecore-Pivot MM is trackling a master Eclipse-UML-Pivot-MM, tooling such as code generators may use the Eclipse Ecore API to access UML meta-models. The UML to Ecore conversion will be performed automatically by the adapters; UML to Pivot, then Pivot to Ecore or vice-versa. A change made in any meta-model dialect will be prtopagayted up via the master pivot to the master meta-model and then propagated down to keep all meta-models coherent.

The master/slave approach will support one master and many slaves, without constraining the master to be UML or Ecore; the approach should be extensible to any meta-model dialect, provided the meta-model dialect supports every concept supported by the MOF Pivot Meta-Model. For Eclipse UML and Ecore, this mostly just requires discovinering the poorly documented EAnnotations used to persist special functionality.

Pivot Structural Model

The Pivot Model isolates OCL from the details of any particular UML or Ecore (or EMOF or CMOF or ...) meta-model representation. OCL expressions can therefore be defined, analyzed and evaluated for a heterogeneous mix of meta-models for which an external representation to pivot model mapping has been defined. (Initially this mapping may be realised as a one shot transformation. In the longer term, the mapping must be a live adaptation in order for the pivot model to update automatically to external changes in the meta-model.)

The Pivot Model is arguably a major omission from the OMG OCL specification, which provides no clues as to how the OCL AST can reference a non-meta-model operation defined by an OperationContextDecl, or how an OperationCallExp can reference a standard library operation since there is no defined URI for the OCL Standard Library.

A custom pivot model may need to be created for each usage since each usage may customise OclAny in distinct ways. However most usages will not customise OclAny, so a lightweight approach is needed for simple usage whose costs are proportionate to complexity.

The Pivot Model is a merged meta-model with a class for each user-defined classifier and for each OCL Standard Library class. A "conformsTo" relationship is established from the "superType" relationships of the user meta-models. The merge imposes the additional OCL "conformsTo" relationships so that each root classifier in the user meta-models "conformsTo" OclType which "conformsTo" OclAny. Similarly OclVoid "conformsTo" each leaf classifier in the user meta-models. Additional model elements introduced by CompleteOCL are incorporated in the pivot model so that there is no observable difference between between a user-defined feature, a CompleteOCL feature or an OCL Standard LIbrary feature.

The Pivot Model needs to accommodate all the class-related concepts of UML, such as AssociationClasses, subset properties and profiles. However there is no need for other facilities such as Use Cases or Deployments. The meta-model of the Pivot Model is therefore perhaps a distinct merge of UML packages analoguous to the Essential MOF merge.

With full class-related facilities in the pivot model, problems such as how to navigate non-navigable opposites in EMOF are isolated as a problem for EMOF and the EMOF to pivot model mapping. Ongoing discussions standardising Tags should allow these problems to be resolved.

The Pivot Model need never be persisted, however its construction is predictable and so the pivot model can be the provider of consistent URIs for use by the OCL AST.

The Pivot Model has explicit generic parameters, just like Java or Ecore or UML, rather than the implicit generics that lurk behind a coherent interpretation of Set(T), Collection::product(T2), Tuple etc.

With a uniform merged representation in the pivot model, it is fairly easy in principle to provide substantial reflective facilities in the pivot model. In practice, provision of reflection could undermine OCL's current support for full static type analysis. This hazard need not arise if the reflection fully generic and so avoids the problems that Java and Ecore had in maintaining compatibility when generics were introduced once reflection was already established.

Pivot AST Model

The primary AST will use the Pivot Model's classes and features. It can be converted between Ecore and UML representations when necessary.

(It is unclear whether the Pivot Model will just be a third binding of the generic binding, or whether an evolution back to non-generic bindings is merited thereby giving 100% compliance with an OMG endorsed Pivot model.)

Pivot Standard Library Model

Using the Pivot Model to represent the OCL standard library allows the OCL Library to be fully model driven, allowing variant OCL standard libraries to realise alternative interpretations of the OCL specifications and extended libraries to support other languages.

The standard library model provides the declarations used by the parser, analyzer and validator and associates a Java class with each feature. Extension or modification therefore requires alternate or additional declarations and/or Java classes.