OCL/Pivot Model

The Pivit 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

Pivot Model

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.