User Interface

User Interface

The user interface comprises

Project Property Pages

The Project Property Pages are accessible by invoking Properties from the right button context menu of a project.

In principle, it is possible to specify project-specific settings, however in practice is not often possible for application code to determine the prevailing project. Project-specific properties are therefore often ignored and may be removed in a future release.

The Property pages are:

Workspace Preference Pages

The Workspace Preference Pages are accessible by invoking Preferences from the Window menu on the toolbar.

The Preference pages are:

Overall Options

The two overall options are independent of the Ecore/UML/Pivot bindings.

Default Delegation Mode

The Eclipse OCL project provides two execution engines which may be used to support EMF Delegates.

EMF Delegate annotations referencing the URI are serviced by the classic evaluator that uses the LPG parser.

This URI was introduced in the Indigo release.

EMF Delegate annotations referencing the URI are serviced by the new experimental evaluator that uses the UML-aligned Pivot model.

This URI was introduced in the Indigo release and was imposed by the Indigo OCLinEcore editor.

EMF Delegate annotations referencing the URI are serviced by the evaluator selected on the preference page by the Default Delegation Mode.

This URI was introduced in the Helios release and was imposed by the Helios OCLinEcore editor.

Use of an Indigo or Juno editor converts the URI to use the Pivot evaluator.

In Kepler, a prevailing URI in the input file is preserved, unless changed by the context menu setting. If no prevailing URI exists a default is determined by an OCLinEcore preference setting that defaults to the Pivot evaluator.

Code Generation Mode

Juno introduced an experimental ability to replace the delegated interpreted execution of OCL by direct execution of compiled Java code. This facility has been substantially improved and tested for the Kepler release.

Optimisations for Luna included inlining the bodies directly into the EMF Impl classes.

Mars has useful fixes and benefits from safe navigation analyses.

Further optimisations are scheduled for future releases.

This option may be selected to change the realization of OCL option.

Delegate for interpretation at run-time

Selecting the default delegation mode retains the Helios and Indigo functionality whereby genmodel generates Java code that encodes the OCL expressions as text strings. Each expression is lazily compiled at run-time with the result being cached to reduce overheads for repeated execution.

Generate Java code in xxxBodies classes

Selecting Java code generation causes genmodel to run Xtend templates that generate

  • a Package file

  • inline OCL implementations within the Class files

The tables file contains an optimised model representation allowing polymorphic operations to be dispatched in constant time.

The implementation files contain Java code corresponding to each OCL expression defining operation bodies or property initializers.

Disclaimer: the generated code is experimental has yet to be optimized and so is only about five times faster than the interpreted execution.

Ecore and UML Options

The options for the Ecore and UML bindings.

UML Options

The options for the UML binding.

Model Registry

The Model Registry is now deprecated.

Syntax Coloring

The standard Xtext syntax coloring facilities are provided for each of the OCL editors.

Editor Templates

The standard Xtext editor template facilities are provided for each of the OCL editors.

OCLinEcore Options

The options for the OCLinEcore editor.

OCL embedded in Ecore can be executed with either the Classic evaluator or the new Pivot evaluator depending on the URI used to define the embedded EAnnotations. This preference determines the URI written to Ecore files when no URI was previously in use.

Selecting makes no choice and so defers to the user’s run-time delegation choice.

Selecting is recommended since the OCLinEcore editor and Pivot evaluator both use the Xtext parser. This should avoid problems whereby not all facilities of the new Pivot grammar are supported by the Classic grammic or LPG evaluator.

Selecting may be appropriate if evaluation using the classic LPG evaluator is important.