doc/org.eclipse.ocl.doc/doc/1010-eclipse-ocls.textile - ocl/org.eclipse.ocl - Git at Google

 h2(#EclipseOCLs). The two Eclipse OCLs

 The Eclipse OCL project is making a transition to a new underlying infrastructure.

 h3. The mature Eclipse OCL metamodels

 The mature 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 M2M/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 making for rather cumbersome Java code for the OCL developers and OCL consumers alike.

 The mature evaluator is tightly coupled to Ecore which might appear efficient, but the lack of separation of OCL-specification semantics from Java-implementation seamntics makes accurate implementation of equality in nested collections hard to achieve.

 The mature code endeavored to comply with OCL specification despite significant ambiguities in the specification, but since the mature 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.

 h3. The pivot Eclipse OCL metamodel

 There is now a significant personnel overlap between the Eclipse OCL committers who maintain/develop the Eclipse OCL implementation and the OMG OCL RTF (Revision Task Force) who maintain the OCL specification.

 The pivot metamodel is a prototype for a resolution of a number of fundamental problems with the OCL 2.2 specification. The pivot metamodel is derived from the UML metamodels for UML and OCL to provide a coherent 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 coherent 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 implemented. This allows a clear separation of OCL-semantics, and although the extra object apparently wrapping each value might appear to incur overheads, we expect to streamline this so that the new structure is accurate and faster.

 h3. The transition

 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.4.oclstdlib library
 * Pivot Evaluator

 When using the mature OCL Console the contributing tools are
 * LPG parser and hand-coded Syntax Helper
 * Ecore (or UML) metamodel bindings
 * Hand coded library implementation
 * Mature evaluator

 Since these tools are different there may be occasions where the increased OMG compliance of the pivot metamodel gives different behavior to the mature metamodels.

 In an intermediate (3.2) release, it is planned to introduce a 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. The org.eclipse.ocl.examples.library and org.eclipse.ocl.examples.pivot plugins will be renamed to org.eclipse.ocl.library and org.eclipse.ocl.pivot.

 In the Juno (3.3) release, the transition should be complete and all org.eclipse.ocl.examples.xtext.* plugins will be renamed to org.eclipse.ocl.xtext.*. All functionality should use the new pivot metamodel by default. However the mature Ecore and UML support will remain for compatibility.

 h3. APIs

 Eclipse OCL has two different styles of APIs

 h4. Tool 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 mature metamodels and org.eclipse.ocl.examples.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 metamodeel representation.

 h4. Internal APIs

 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 mature 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.
	h2(#EclipseOCLs). The two Eclipse OCLs

	The Eclipse OCL project is making a transition to a new underlying infrastructure.

	h3. The mature Eclipse OCL metamodels

	The mature 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 M2M/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 making for rather cumbersome Java code for the OCL developers and OCL consumers alike.

	The mature evaluator is tightly coupled to Ecore which might appear efficient, but the lack of separation of OCL-specification semantics from Java-implementation seamntics makes accurate implementation of equality in nested collections hard to achieve.

	The mature code endeavored to comply with OCL specification despite significant ambiguities in the specification, but since the mature 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.

	h3. The pivot Eclipse OCL metamodel

	There is now a significant personnel overlap between the Eclipse OCL committers who maintain/develop the Eclipse OCL implementation and the OMG OCL RTF (Revision Task Force) who maintain the OCL specification.

	The pivot metamodel is a prototype for a resolution of a number of fundamental problems with the OCL 2.2 specification. The pivot metamodel is derived from the UML metamodels for UML and OCL to provide a coherent 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 coherent 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 implemented. This allows a clear separation of OCL-semantics, and although the extra object apparently wrapping each value might appear to incur overheads, we expect to streamline this so that the new structure is accurate and faster.

	h3. The transition

	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.4.oclstdlib library
	* Pivot Evaluator

	When using the mature OCL Console the contributing tools are
	* LPG parser and hand-coded Syntax Helper
	* Ecore (or UML) metamodel bindings
	* Hand coded library implementation
	* Mature evaluator

	Since these tools are different there may be occasions where the increased OMG compliance of the pivot metamodel gives different behavior to the mature metamodels.

	In an intermediate (3.2) release, it is planned to introduce a 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. The org.eclipse.ocl.examples.library and org.eclipse.ocl.examples.pivot plugins will be renamed to org.eclipse.ocl.library and org.eclipse.ocl.pivot.

	In the Juno (3.3) release, the transition should be complete and all org.eclipse.ocl.examples.xtext.* plugins will be renamed to org.eclipse.ocl.xtext.*. All functionality should use the new pivot metamodel by default. However the mature Ecore and UML support will remain for compatibility.

	h3. APIs

	Eclipse OCL has two different styles of APIs

	h4. Tool 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 mature metamodels and org.eclipse.ocl.examples.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 metamodeel representation.

	h4. Internal APIs

	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 mature 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.