Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "OCL/Pivot Model"
m |
m (Ed.willink.me.uk moved page MDT/OCL/Pivot Model to OCL/Pivot Model: Decontainerizing) |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 17: | Line 17: | ||
=== MOF-compliant modeling === | === 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 | + | Ecore is slightly different to EMOF and consequently Eclipse UML is slightly different to OMG UML. This can be very awkward when strict 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. | 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. | 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. | ||
| + | |||
| + | ==== UnifiedOCL editor ==== | ||
| + | |||
| + | The [[MDT/OCL/OCLinEcore | OCLinEcore]] editir will be enhanced to support the full capabilities of the Pivot Meta-Model and so will support concepts such as Association and subsetting properties, with first class OMG-like textual syntaxes. This will make advanced Ecore facilities such as [http://www.eclipse.org/modeling/emf/docs/overviews/FeatureMap.pdf EFeatureMap] directly accessible to modellers. | ||
=== Dynamic UML === | === Dynamic UML === | ||
| Line 29: | Line 33: | ||
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. | 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 | + | The master/slave relationship between Pivot Meta-Models should make this transparent. When a slave Eclipse-Ecore-Pivot MM is tracking 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 propagated 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. | 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. | ||
| + | === OCL === | ||
| + | The primary motivation for this infrastructure is to fully support OCL for which referenceable declarations may originate from user-defined meta-models, the OCL-defined standard library or from user-supplied Complete OCL documents. | ||
| − | + | The OCL specification neglects to specify how library and document contributions can be referenced. The Pivot meta-model is therefore a prototype for a future OMG OCL resolution of these oversights. | |
| − | + | ||
| − | The | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | The Pivot | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | The three sources of declarations are merged to form a merged OCL-Pivot-MM instance which provides the uniform treatment of the diverse declaration sources without corrupting the sources. The OCL pivot model tracks changes to the defining models but does not propagate changes backwards. Access through the OCL API will therefore provide read-only access to the merged model. | |
| − | + | Since the OCL pivot model tracks in only one direction, it may be appropriate to normalise certain difficulties such as unnavigable opposites in the merged model, where the merged copies can be changed without impacting the source definitions. | |
| − | The Pivot Model | + | == The Pivot Meta-Model == |
| − | + | The Pivot Meta-model should be identical to anything that a future version of the OMG OCL specification endorses as the solution to resolving diverse declaration references. The OMG OCL specification is evolving to resolve UML alignment issues and so any Pivot Meta-model proposal that is poorly aligned with UML is unlikely to be adopted. | |
| − | + | It would appear that the Pivot Meta-model should be as similar to UML as possible. This can probably be achieved by defining the Pivot Meta-model as a distinct merge of relevant UML Infrastructure packages. | |
| − | + | === Implementation Approach === | |
| − | + | The Ecore meta-model is defined by Ecore.ecore and realised with the assistance of Ecore.genmodel and Ecore JET templates as Ecore*.java and Ecore*Impl.java where Ecore* denotes the many classes such as EAttribute etc that realise the model. | |
| − | + | The UML meta-model is similarly defined by UML.ecore and realised with the assistance of UML.genmodel and Ecore/UML JET templates as UML*.java and UML*Impl.java where UML* denotes the many classes such as Property etc that realise the model. | |
| − | + | The Pivot meta-model is defined by Pivot.ecore and realised with the assistance of Pivot.genmodel and Ecore JET templates as Pivot*.java where Pivot* denotes the many interfaces such as PivotProperty etc that realise the model. It may be that only Pivot interfaces are used. | |
| − | The | + | The mapping from Pivot to Ecore or UML is defined by Pivot2Ecore.qvtr or Pivot2UML.qvtr from which a bespoke Acceleo Java code generation provides the EcorePivot*.java or UMLPivot*.java adapters. Note that QVTr is used as a convenient declarative syntax; the QVTr is not executed, so the lack of a QVTr execution engine is not a problem. The QVTr declarative structure captures the pair-wise mapping of Pivot to Ecore names, and for the leaves, some statement such as: readOnly := inverted(changeable); identifies 'inverted' as an irregular mapping policy hard coded in the Acceleo code generator template. Acceleo therefore replaces JET, and a *.qvtr replaces a *.genmodel in the 'conventional' form of Java generation. |
Latest revision as of 13:39, 15 May 2016
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.
Contents
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 strict 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.
UnifiedOCL editor
The OCLinEcore editir will be enhanced to support the full capabilities of the Pivot Meta-Model and so will support concepts such as Association and subsetting properties, with first class OMG-like textual syntaxes. This will make advanced Ecore facilities such as EFeatureMap directly accessible to modellers.
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 tracking 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 propagated 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.
OCL
The primary motivation for this infrastructure is to fully support OCL for which referenceable declarations may originate from user-defined meta-models, the OCL-defined standard library or from user-supplied Complete OCL documents.
The OCL specification neglects to specify how library and document contributions can be referenced. The Pivot meta-model is therefore a prototype for a future OMG OCL resolution of these oversights.
The three sources of declarations are merged to form a merged OCL-Pivot-MM instance which provides the uniform treatment of the diverse declaration sources without corrupting the sources. The OCL pivot model tracks changes to the defining models but does not propagate changes backwards. Access through the OCL API will therefore provide read-only access to the merged model.
Since the OCL pivot model tracks in only one direction, it may be appropriate to normalise certain difficulties such as unnavigable opposites in the merged model, where the merged copies can be changed without impacting the source definitions.
The Pivot Meta-Model
The Pivot Meta-model should be identical to anything that a future version of the OMG OCL specification endorses as the solution to resolving diverse declaration references. The OMG OCL specification is evolving to resolve UML alignment issues and so any Pivot Meta-model proposal that is poorly aligned with UML is unlikely to be adopted.
It would appear that the Pivot Meta-model should be as similar to UML as possible. This can probably be achieved by defining the Pivot Meta-model as a distinct merge of relevant UML Infrastructure packages.
Implementation Approach
The Ecore meta-model is defined by Ecore.ecore and realised with the assistance of Ecore.genmodel and Ecore JET templates as Ecore*.java and Ecore*Impl.java where Ecore* denotes the many classes such as EAttribute etc that realise the model.
The UML meta-model is similarly defined by UML.ecore and realised with the assistance of UML.genmodel and Ecore/UML JET templates as UML*.java and UML*Impl.java where UML* denotes the many classes such as Property etc that realise the model.
The Pivot meta-model is defined by Pivot.ecore and realised with the assistance of Pivot.genmodel and Ecore JET templates as Pivot*.java where Pivot* denotes the many interfaces such as PivotProperty etc that realise the model. It may be that only Pivot interfaces are used.
The mapping from Pivot to Ecore or UML is defined by Pivot2Ecore.qvtr or Pivot2UML.qvtr from which a bespoke Acceleo Java code generation provides the EcorePivot*.java or UMLPivot*.java adapters. Note that QVTr is used as a convenient declarative syntax; the QVTr is not executed, so the lack of a QVTr execution engine is not a problem. The QVTr declarative structure captures the pair-wise mapping of Pivot to Ecore names, and for the leaves, some statement such as: readOnly := inverted(changeable); identifies 'inverted' as an irregular mapping policy hard coded in the Acceleo code generator template. Acceleo therefore replaces JET, and a *.qvtr replaces a *.genmodel in the 'conventional' form of Java generation.