Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "MDT/OCL/4.X Architecture"
| (11 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | The planned Architecture for | + | The planned Architecture for OCL 4.X is based around a [[OCL/Pivot Model | Pivot Model]] as shown in |
[[Image:MDT-OCL-4.x-architecture.png|750px]] | [[Image:MDT-OCL-4.x-architecture.png|750px]] | ||
| Line 7: | Line 7: | ||
==== Pivot Structural Model ==== | ==== Pivot Structural Model ==== | ||
| − | The Pivot Model isolates the details of | + | 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 | + | 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 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 ==== | ==== Pivot AST Model ==== | ||
| − | The primary AST will | + | 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- | + | (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 ==== | ==== 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 | + | 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. | 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. | ||
| − | === | + | === Evaluator === |
| − | The | + | The Standard Library defines classes, operations, properties and associated "conformsTo" relationships. These definitions can capture large parts of the OCL specification and so can allow alternate official and unofficial variants of the language to be configured just by selecting an alternate 'standard' library model. Decorating each standard library feature, by a Java class that realises it, provides for easy tailoring to alternate or additional behaviour. |
| + | |||
| + | In order to provide flexibility beyond Ecore models, it may be appropriate to localise model access to allow replacement. The model access needs to support meta-model evolution in order to allow users to experiment with alternate meta-model constraints without having to reload within the Interactive OCL Console. | ||
=== Xtext editors === | === Xtext editors === | ||
| − | Four Xtext editors support different aspects of OCL usage. | + | Four Xtext editors support different aspects of OCL usage. The highly model-driven nature of Xtext ensures that many behaviours that can be sensibly derived from the meta-model are so derived. The editors therefore acquire many useful functions with very little development effort, and will hopefully acquire many more as Xtext matures. |
| − | ==== | + | ==== CompleteOCL Editor ==== |
This editor supports development of an OCL Document in accordance with Section 12 of the OMG OCL specification. A Complete OCL Document complements an independent meta-model. | This editor supports development of an OCL Document in accordance with Section 12 of the OMG OCL specification. A Complete OCL Document complements an independent meta-model. | ||
| − | ==== | + | ==== OCLinEcore Editor ==== |
This editor supports combined development of an Ecore meta-model and OCL constraints upon that meta-model. Editing may be performed directly on a *.ecore XMI file for compatibility with existing working practices, or on a *.oclinecore text file so that detailed whitespace and commenting is preserved. | This editor supports combined development of an Ecore meta-model and OCL constraints upon that meta-model. Editing may be performed directly on a *.ecore XMI file for compatibility with existing working practices, or on a *.oclinecore text file so that detailed whitespace and commenting is preserved. | ||
| − | ' | + | 'OCLinEcore' may prove to be a bit of a misnomer since the Concrete Syntax has nothing to do with Ecore; although there is a syntax for every Ecore concept (including EReference.keys and EAnnotation.contents). This syntax can be extended to Associations and State Machines and subset feature derivation thereby supporting a useful 'OCLinUML'. |
| − | Perhaps this editor should be ' | + | Perhaps this editor should be 'UnifiedOCL' borrowing the U from UML. |
| − | ==== | + | ==== EssentialOCL Editor ==== |
| − | This editor supports editing a single OCL Expression. It is not anticipated that this editor will be used in isolation, rather it is intended for use in pop-ups within other tools that exploit OCL. | + | This editor supports editing a single OCL Expression. It is not anticipated that this editor will be used in isolation, rather it is intended for use in pop-ups within other tools that exploit OCL. It should form the basis of expression entry in the Interactive OCL Console. |
==== OCLstdlib Editor ==== | ==== OCLstdlib Editor ==== | ||
| − | This editor facilitates development of the OCL 'Standard' Library definition. It is | + | This editor facilitates development of the OCL 'Standard' Library definition. It is primarily intended for use by language developers. However OCL-based languages that encourage user-defined library extension may want to make the OCLstdlib editor available to users. |
=== Xtext integration === | === Xtext integration === | ||
| − | Xtext uses an ANTLr parser which is very different to the LPG parser used in MDT/OCL pre 4.X. | + | [http://wiki.eclipse.org/Xtext Xtext] uses an [http://en.wikipedia.org/wiki/ANTLR ANTLr] parser which is very different to the [http://en.wikipedia.org/wiki/LALR_Parser_Generator LPG] parser used in MDT/OCL pre 4.X. |
The LPG parser is probably faster and has a significant API obligation, so discarding the LPG parser is not an option so a way for the two parsers to coexist is required. | The LPG parser is probably faster and has a significant API obligation, so discarding the LPG parser is not an option so a way for the two parsers to coexist is required. | ||
| − | The ANTLr LL grammar is less powerful and so less precise | + | The ANTLr LL grammar is less powerful and so less precise than the LPG LALR grammar. However the Xtext semantic resolution performed by the "linking and scope services" mean that the Xtext CST is considerably more accurate than the LPG CST. |
| + | |||
| + | In the LPG CST, "MyClass" is a text string in a valid syntactic context. The Analyzer is responsible for performing the name to EObject resolution while building the AST. | ||
| + | |||
| + | In the Xtext CST, "MyClass" is a text string that the "linking and scope services" has resolved to a semantically consistent EObject whose name is "MyClass". The Xtext CST therefore needs only a simple mapping to align with an OMG compliant AST. | ||
| − | The "linking and scope services" are realised by ScopeAdapters on CST | + | The "linking and scope services" are realised by a ScopeAdapters on each CST object with functionality closely resembling "Inherited Attributes" and "Synthesized Attributes" from the OMG specification. It therefore seems that the LPG compatibility problem may be resolved by using slightly different ScopeAdapters on the LPG CST so that the functionality currently distributed in diversely named methods in the Analyzer class migrate to polymorphic methods in ScopeAdapter classes. |
=== MDT/OCL 3.X status === | === MDT/OCL 3.X status === | ||
Latest revision as of 13:46, 15 May 2016
The planned Architecture for OCL 4.X is based around a Pivot Model as shown in
Contents
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 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.
Evaluator
The Standard Library defines classes, operations, properties and associated "conformsTo" relationships. These definitions can capture large parts of the OCL specification and so can allow alternate official and unofficial variants of the language to be configured just by selecting an alternate 'standard' library model. Decorating each standard library feature, by a Java class that realises it, provides for easy tailoring to alternate or additional behaviour.
In order to provide flexibility beyond Ecore models, it may be appropriate to localise model access to allow replacement. The model access needs to support meta-model evolution in order to allow users to experiment with alternate meta-model constraints without having to reload within the Interactive OCL Console.
Xtext editors
Four Xtext editors support different aspects of OCL usage. The highly model-driven nature of Xtext ensures that many behaviours that can be sensibly derived from the meta-model are so derived. The editors therefore acquire many useful functions with very little development effort, and will hopefully acquire many more as Xtext matures.
CompleteOCL Editor
This editor supports development of an OCL Document in accordance with Section 12 of the OMG OCL specification. A Complete OCL Document complements an independent meta-model.
OCLinEcore Editor
This editor supports combined development of an Ecore meta-model and OCL constraints upon that meta-model. Editing may be performed directly on a *.ecore XMI file for compatibility with existing working practices, or on a *.oclinecore text file so that detailed whitespace and commenting is preserved.
'OCLinEcore' may prove to be a bit of a misnomer since the Concrete Syntax has nothing to do with Ecore; although there is a syntax for every Ecore concept (including EReference.keys and EAnnotation.contents). This syntax can be extended to Associations and State Machines and subset feature derivation thereby supporting a useful 'OCLinUML'.
Perhaps this editor should be 'UnifiedOCL' borrowing the U from UML.
EssentialOCL Editor
This editor supports editing a single OCL Expression. It is not anticipated that this editor will be used in isolation, rather it is intended for use in pop-ups within other tools that exploit OCL. It should form the basis of expression entry in the Interactive OCL Console.
OCLstdlib Editor
This editor facilitates development of the OCL 'Standard' Library definition. It is primarily intended for use by language developers. However OCL-based languages that encourage user-defined library extension may want to make the OCLstdlib editor available to users.
Xtext integration
Xtext uses an ANTLr parser which is very different to the LPG parser used in MDT/OCL pre 4.X.
The LPG parser is probably faster and has a significant API obligation, so discarding the LPG parser is not an option so a way for the two parsers to coexist is required.
The ANTLr LL grammar is less powerful and so less precise than the LPG LALR grammar. However the Xtext semantic resolution performed by the "linking and scope services" mean that the Xtext CST is considerably more accurate than the LPG CST.
In the LPG CST, "MyClass" is a text string in a valid syntactic context. The Analyzer is responsible for performing the name to EObject resolution while building the AST.
In the Xtext CST, "MyClass" is a text string that the "linking and scope services" has resolved to a semantically consistent EObject whose name is "MyClass". The Xtext CST therefore needs only a simple mapping to align with an OMG compliant AST.
The "linking and scope services" are realised by a ScopeAdapters on each CST object with functionality closely resembling "Inherited Attributes" and "Synthesized Attributes" from the OMG specification. It therefore seems that the LPG compatibility problem may be resolved by using slightly different ScopeAdapters on the LPG CST so that the functionality currently distributed in diversely named methods in the Analyzer class migrate to polymorphic methods in ScopeAdapter classes.
MDT/OCL 3.X status
Much of the proposed MDT/OCL 4.X architecture evolved during MDT/OCL 3.X.
The Standard Library model-driven evaluator may be found in a ReflectiveLibrary branch in CVS, however the work to fully integrate it with the LPG analyzer was too ambitious to complete for 3.0.0M6 so the evaluator remains difficult to extend and with a few (hopefully very obscure) errors in 3.0.0.
The Xtext editors are present in MDT/OCL 3.0.0 as Examples with a plausible though almost certainly incomplete realisation of the "linking and scope services". The "map and merge" supports only referencing external meta-models, so there is no ability for the Xtext editors to produce ASTs, and there is no validation of well-formedness rules.