MDT-OCL 3.0.0 API Changes

One of the main goal to achieve in the MDT-OCL 3.0.0 release is migrating all grammars and parsing infrastructure so that they are based on the last version of LPG 2, whose runtime is sensibly improved and will allow to introduce a fancy textual OCL editor which will help the user to create OCL expressions. An OCL extending language will need to change their grammars/parsing infrastructure if they want to extend OCL in 3.0.0. A changes log and some advice for OCL extenders have been registered here.

MDT-OCL 3.0.0 Capabilities

The bug 299344 provides information about how the capabilities will be dealt in the Helios release. In order to comply with this requirement, we provide documentation about how to define a proper Activity definition for MDT-OCL 3.0.0 which may be used by third parties to configure their product capabilities:

Note: The code above just provides the Activity definition. A proper capabilities configuration should provide a "category" and a "categoryActivityBinding". You also have a complete capabilities configuration in the "org.eclipse.ocl.capabilities" plugin from CVS.

Milestone 2

invalid/Invalid/OclInvalid resolved

The OMG OCL 2.0 specification is very unclear as to the relative status of invalid objects and types. The tentative OCL 2.1 specification is little better.

The problem is easily understood by contrasting invalid with the uncontentious null: null is the null object that is the sole instance of the OclVoid which is the sole instance of VoidType meta-class.

Section 8.2 tends to suggest that: OclInvalid is the invalid object that is the sole instance of Invalid which is the sole instance of the InvalidType meta-class. This is what MDT-OCL 1.3.0 realises.

Section 11.2.4 and 11.2.5 are much more consistent in preferring: invalid is the invalid object that is the sole instance of OclInvalid which is the sole instance of the InvalidType meta-class. This is the revised implementation for MDT-OCL 3.0.0.

Beware. This change has a significant API incompatibility; the OCLStandardLibrary methods getOclInvalid and getInvalid have interchanged semantics. All calls to getOclInvalid and getInvalid should be reviewed, since errors may be silent. Concrete syntax changes are less likely to cause trouble.

Comments parsed

static features supported for the UML binding

The proposed OCL enhancement to allow a 'static' keyword prefix to a 'def' constraint is implemented for the UML binding, unless ParsingOptions.SUPPORT_STATIC_FEATURES is set false in the Environment, in which case an error is generated.

Ecore does not support static EStructuralFeatures and so use of 'static' gives an error when the ECore binding is used.

setStatic, isConstraint and isPackage are added to the UMLReflection API.

CST inelegancies removed

@pre is now represented by a non-null rather than null IsMarkedPreCS object. Previously this was coded by a true/false value of the IsMarkedPreCS.isPre field. Analyzer code explicitly handling IsMarkedPreCS objects must be revised to handle the null object logic.

InvCS, DefCS, InitCS and DerCS are now maintained in a PropertyContextCS.constraints or ClassifierContextDecl.constraints array. The reverse lexical order linked list daisy chain is no longer supported.

PathNameCS.simpleNames and StateExpCS.simpleNames replace PathNameCS.sequenceOfNames and StateExpCS.sequenceOfNames. This changes a List<String> to a List<SimpleNameCS> which avoids loss of IToken context.

The spelling of many production names is changed, mostly in just the first letter.

The term factoring of some productions has changed.

As a result problems with if and let are resolved.

It is also temporarily possible to use non-reserved words in many contexts where the specification currently allows them. An OMG issue will be raised to make self, true, Bag etc reserved words.

The Essential OCL grammar is now completely separable so that re-users can avoid any grammar baggage from Complete OCL. Re-users may re-use EssentialOCL.g, EssentialOCLLexer.g and EssentialOCLKWLexer.g.

Milestone 4

OCL 1.4.0 compatibility release abandoned.

EMF EModelElement change

EMF's EModelElement no longer reports EObject operations in eAllOperations(), so OCL expressions invoked on meta-models that extend EModelElement and invoke methods such as eContainer(), eContents() or eGet() will fail.

Visibility of these methods was not compliant with the OCL specification, so this EMF change will not be hidden.

Methods such as oclContainer(), oclContents() and oclGet() are planned for MDT/OCL 4.0.0.

Milestone 5

LPG v2.0.17 adoption

In M5, the parsing infrastructure has changed so that now it relies on LPG v2.0.17. Some reasons for accomplishing this change are the follwing:

We tend to ship an OCLEditor as an example which uses IMP, which uses LPGv2. So, since LPGv2 will be needed by the example it should be good that the parser uses the same runtime, and we could then forget the old one.

Technically, LPGv2.x runtime has been refactored improving its design, including more interfaces, etc which should also be exploited by MDT-OCL. As long as possible, MDT-OCL 3.0.0 will take advantage from the LPG's templates and API changes.

Technically, LPGv1.x runtime has some deficiences relating performance and memory usage. For instance, an identified issue related to the backtracking parser which used an IntTuple action = new IntTuple(1 << 20) to stack parser actions. In Lpg v2.x an improved dinamic array is used instead, which shouldn't use so amount of memory: private IntSegmentedTuple action = new IntSegmentedTuple(10, 1024)

Some bugzillas related to this new LPG v2.0.17 runtime adoption, which have been introduced in M5:

Milestone 6

OCLinEcore

Milestone 7

All OCL Examples renamed from org.eclipse.emf.ocl.examples... to org.eclipse.ocl.examples...

Four Xtext editor examples have been added. The decision to redevelop these editors using Xtext, rather than migrate the IMP editors from M2M/QVTd 289761 was occasioned by IP issues and the very model-aligned Xtext capabilities that arose at EclipseCon after M6. The editors are therefore very new. Expect significant improvements as they and Xtext mature.

CompleteOCL editor

This editor supports development of a textual *.ocl document that complements a *.ecore meta-model using the syntax of Section 12 of the OMG specification. Additionally an import statement is supported.

Use New Project->Examples->Royal and Loyal Example for an example project.

OCLinEcore editor

This editor supports development of OCL within an Ecore model using a textual syntax that covers all Ecore and OCL concepts. See OCLinEcore.

If the editor is invoked on a *.ecore model, it is saved back as *.ecore, unless SaveAs OCLinEcore is used from the Document entry on the Outline menu to save as *.oclinecore, which persists the textual format.

EssentialOCL editor

This editor supports development of a textual *.essentialocl document that comprises a single OCL expression. It is unlikely that this editor would be used standalone. It is anticipated that it will be useful as a pop-up within other tools.

OCLstdlib editor

This editor supports development of the OCL standard library definition, that is used by the Xtext editors, and which in OCL 4.0.0 will form the extensible definition of all analysis and evaluation. The default OCL standard library may be found in the model folder of the essentialocl editor.