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

Revision as of 07:01, 21 May 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.

Complete OCL 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.

OCL in Ecore 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.

'OCL in Ecore' may prove to be a bit of a misnomer since the Concrete Syntax has nothing to do with Ecore; just an syntax for every Ecore concept. This syntax can be extended to Associations and State Machines and subset feature derivation thereby supporting a useful 'OCL in UML'.

Perhaps this editor should be 'Unified OCL' borrowing the U from UML.

Essential OCL 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.

OCLstdlib Editor

This editor facilitates development of the OCL 'Standard' Library definition. It is only intended for use by language developers.

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 that 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. The Xtext CST needs just a simple mapping to migrate classes and features to slightly different names and structures in the AST.

The "linking and scope services" are realised by ScopeAdapters on CST objects 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.