Difference between revisions of "MDT/OCL/4.X Architecture"

Revision as of 12:23, 12 June 2010

The planned Architecture for MDT/OCL 4.X is based around a Pivot Model as shown in

Pivot Model

Pivot Structural Model

The Pivot Model isolates the details of the UML or Ecore (or EMOF or CMOF or ...) meta-model representation, so that alternate formats can be accommodated without impacting the core of the architecture and without problems regarding heterogeneous model representation references.

The Pivot Model also normalises the diverse sources of declarations so that

• meta-model defined (e.g. MyClass::getName())
• meta-model implied (e.g. a non-navigable opposite)
• standard library defined (e.g. allInstances())
• Complete OCL additions (e.g. def: MyClass::isNamed() : Boolean)

are uniformly referenceable.

Pivot AST Model

The primary AST will be based on the Pivot model and 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-genetic 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 interpreations 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.

Pivot Generics

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.

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