OCL/FAQ

In addition to the FAQ below, see also the OCL Developer Guide documentation included in the OCL SDK.

Newbie / General

Questions in this section are directed at those that are new to the Eclipse OCL component and are interested in finding out how to begin working with it.

What is the difference between EMF OCL, MDT OCL and Eclipse OCL?

Vintage.

• EMF OCL describes the original IBM sponsored development as part of a variety of EMF activities
• MDT OCL describes the next phase after a re-organisation of EMF activities at Eclipse introduced EMF, MDT, M2M container projects
• Eclipse OCL describes the post-Kepler phase once container projects became obsolete.

What is the difference between Dresden OCL and Eclipse OCL?

Dresden OCL and Eclipse OCL are independent Open Source developments by independent teams. There is little commonality beyond best endeavours to comply with the OCL specification and exploitation of EMF as the underlying modeling infrastructure.

What is the difference between IBM RSA OCL and Eclipse OCL?

IBM RSA bundles a couple of org.eclipse.ocl plugins, which deviate in unknown ways from the official Eclipse OCL plugins. The presence of the unofficial plugins prevent installation of Eclipse OCL and so they must be uninstalled in order to gain access to the substantial UI facilities that Eclipse OCL provides.

What is Eclipse OCL?

Eclipse OCL provides extensible parsers, evaluators, validators, code generator and debuggerer for OCL constraints and expressions on any EMF-based metamodel. That is for any metamodel whose meta-metamodel is Ecore, and consequently provides an EMF importer to create GenModels that generate a Java implementation.

Traditionally, the Eclipse Modeling Project has two such metamodels: Ecore and UML (Ecore being its own meta-metamodel). Hence, the Classic OCL component provides a distinct OCL binding for each of these metamodels. OCL can parse constraints in either Ecore or UML models, and can evaluate them on the instances of Java classes generated from these models. The new Pivot (or Unified) OCL component provides a single Pivot representation with distinct Ecore and UML metamodel loaders.

The new Pivot metamodel is used to support Editors, direct Java Code Generation and debugging.

In terms of the OMG's modeling "stack", then, we have in the Eclipse Modeling Project

OCL's relation to the OMG modeling stack

Modeling Level	Artifacts	OCL's Role
M3	Ecore	This is the metamodel for the OCL Abstract Syntax Model
M2	Ecore, UML	OCL's generic AST model binds to these metamodels
M1	*.ecore and *.uml models	OCL parses constraints on these models
	generated Java code
M0	instances of generated Java classes	OCL evaluates constraints on these objects
	dynamic EMF objects

The OCL Abstract Syntax Model is, itself, actually a metamodel sitting at the M2 level.

The use of Mn levels can be confusing, since OCL just evaluates expressions on instances, so if your instances are not at M0, your other levels are correspondingly adjusted.

Pivot metamodel

The Pivot metamodel is a merge of the OCL metamodel with parts of the UML meta-model. This enables an OMG-compliant metamodel to be used.

In terms of the OMG's modeling "stack", then, we have in the Eclipse Modeling Project

OCL's relation to the OMG modeling stack

Modeling Level	Artifacts	OCL's Role
M3	Pivot	This is the metamodel for the OCL Abstract Syntax Model
M2	Pivot	OCL's generic AST model binds to these metamodels
M1	*.ecore, *.uml, *.ocl models	OCL parses constraints on these models
	generated Java code
M0	instances of generated Java classes	OCL evaluates constraints on these objects
	dynamic EMF objects

What is Eclipse OCL update site URL?

http://download.eclipse.org/modeling/mdt/ocl/updates/releases

Eclipse OCL Repositories and Updates for Milestone, Interim and Nightly builds are described in P2 Repositories Organization.

How do I learn OCL?

The object constraint language: getting your models ready for MDA, by Jos B. Warmer, Anneke G. Kleppe is very readable and thoroughly recommended.

Clause 7 of the OMG specification is surprisingly readable.

You can Google "OCL Tutorial" for many online alternatives.

What versions of Java and Eclipse does Eclipse OCL work with?

Because Eclipse OCL extends EMF's Ecore, OCL's core dependencies are generally the same as those of EMF.

OCL	Plugins	Eclipse	Minimum JVM	Platform	EMF	UML	Xtext
2006	1.0	Callisto	1.4.2	3.2	2.2	2.0
2007	1.1	Europa	1.5	3.3	2.3	2.1
2008	1.2	Ganymede	1.5	3.4	2.4	2.2
2009	1.3	Galileo	1.5	3.5	2.5	3.0
2010	3.0	Helios	1.5	3.6	2.6	3.1	1.0
2011	3.1	Indigo	1.5	3.7	2.7	3.2	2.0
2012	4.0/3.2	Juno	1.5	3.7 to 4.2	2.7 to 2.8	4.0	2.3 to 2.4
2013	4.1/3.3	Kepler	1.5 $1	3.7 to 4.3	2.9	4.0 to 4.1	2.4.2
2014	5.0/3.4	Luna	1.5/1.6 $4	3.7 to 4.4	2.8 to 2.10	4.0 to 5.0	2.3 to 2.6
2015	6.0/3.5/1.0	Mars	1.5/1.7 $4	3.7 to 4.5	2.8 to 2.11	5.0 to 5.1	2.3 to 2.8
2016	6.1/3.6/1.1	Neon	1.5/1.8 $4	4.4 to 4.6	2.10 to 2.12	5.0 to 5.2	2.7 to 2.10 $2
2016	6.2/3.6/1.2	Neon++	1.5/1.8 $4	4.4 to 4.6	2.10 to 2.12	5.0 to 5.2	2.10
2017	6.3/3.7/1.3	Oxygen	1.5/1.8 $4	4.4 to 4.7	2.10 to 2.13	5.0 to 5.3	2.10 to 2.12
2018	6.4/3.8/1.4	Photon	1.5/1.8 $4	4.4 to 4.8	2.10 to 2.14 $3	5.0 to 5.4	2.10 to 2.14
2018-09	6.5/3.9/1.5	2018-09	1.5/1.8 $4	4.4 to 4.9	2.10 to 2.15 $3	5.0 to 5.4.1	2.10 to 2.15
2018-12	6.6/3.10/1.6	2018-12	1.5/1.8 $4	4.4 to 4.10	2.10 to 2.16 $3	5.0 to 5.5	2.10 to 2.16
2019-03	6.7/3.11/1.7	2019-03	1.5/1.8 $4	4.4 to 4.11	2.10 to 2.17	5.0 to 5.5.1	2.10 to 2.17
2019-06	6.8/3.12/1.8	2019-06	1.5/1.8 $4	4.4 to 4.12	2.10 to 2.18	5.0 to 5.5.1	2.10 to 2.18
2019-09	6.9/3.13/1.9	2019-09	1.5/1.8 $4	4.4 to 4.13	2.10 to 2.19	5.0 to 5.5.1	2.10 to 2.19
2019-12	6.10/3.14/1.10	2019-12	1.5/1.8 $4	4.4 to 4.14	2.10 to 2.20	5.0 to 5.5.1	2.10 to 2.20
2020-03	6.11/3.15/1.11	2020-03	1.5/1.8 $4	4.4 to 4.15	2.10 to 2.21	5.0 to 5.5.1	2.10 to 2.21
2020-06	6.12/3.16/1.12	2020-06	1.5/1.8 $4	4.4 to 4.16	2.10 to 2.22	5.0 to 5.5.1	2.10 to 2.22
(2020-06)	6.12/3.16/1.12	2020-09	1.5/1.8/11 $4	4.4 to 4.17	2.10 to 2.23	5.0 to 5.5.1	2.10 to 2.23
2020-12	6.13/3.17/1.13	2020-12	1.5/1.8/11 $4	4.4 to 4.18	2.10 to 2.24	5.0 to 5.5.1	2.10 to 2.24
2021-03	6.14/3.18/1.14	2021-03	1.5/1.8/11 $4	4.4 to 4.18	2.10 to 2.25	5.0 to 5.5.1	2.10 to 2.25

"to" ranges are inclusive.

See also EMF 2.3 JVM Requirements.

The UML dependencies may be ignored if support for UML models is not required.

The Xtext dependencies may be ignored if the OCL editors are not required.

$1 Java 1.6 is needed if on the fly compilation of OCL derived Java is required.

$2 Xtext 2.8.4 or earlier is used regenerate the editors and must be used to generate extended editors.

$3 EMF 2.14 is required if EMF's genmodel is used to convert OCL to Java.

$4 The minimum JVM is that for the platform. The Classic OCL has not advanced beyond Java 5 VM. The Pivot OCL requires only a Java 8 VM.

How do I solve: "#" unexpected character ignored

In OCL 1.3 a '#' character was used to indicate an enumeration value, and so there are misleading examples such as

 self.allConnections->select(aggregation <#none)->size <= 1

from Section 2.5.3 of UML 1.5 that suggest that # is a prefix for an Enumeration Literal. This syntax was removed in OCL 2.0.

Enumeration Literals should be qualified by their Enumeration name: e.g. AggregationKind::none.

OCL Formulation

This section answers common problems in the formulation of OCL expressions that achieve some specific aim. More often than not, these are matters of OCL-the-language, not specific in any way to the Eclipse OCL implementation.

How do I modify an Object in OCL?

OCL is a side-effect-free declarative specification language that operates primarily on objects.

OCL is almost useless by itself. You have to embed OCL in some context in order to provide the objects on which an OCL expression operates. Thus:

• OCLinEcore embeds OCL in a model to enrich the model with invariants, operations and property initializers.
• QVTo embeds OCL in an Imperative language to support model transformation and manipulation
• QVTc, QVTr embed OCL in a Declarative language to support model-to-model transformation
• MOFM2T, Acceleo embed OCL in a Declarative language to support model-to-text transformation

OCL is side-effect free, so OCL cannot change anything and nothing may change while an OCL evaluation is in progress.

If you want OCL to change something, you may use OCL to compute a new value or model, but your embedding context is responsible for installing the change.

How do I combine collections of different types?

Using the Pivot OCL

If you have two or more collections of distinct element types and want to combine them into a single collection, you may use a union operation for which the most derived common type is selected. In the event of a typo, this may well be OclAny. You may use oclAsType to cast a Collection to a more convenient type.

Using the Classic OCL

If you have two or more collections of distinct element types and want to combine them into a single collection, it is not as simple as just unioning them or casting the collections to a common type. In the OCL 2.0 specification, the collection types do not conform to OclAny, so they do not have the oclAsType operation. Also, the semantics of generic type parameters in collections are undefined, so that it is not clear whether, for example, Set(T) has only union(Set(T)) or also union(Set(S)) where S is any supertype of T.

Instead, one must do something like:

-- given types A, B conforming to S but neither of
-- A nor B conforming to the other
context S
def: union(a : Set(A), b : Set(B)) : Set(S) =
    let s : Set(S) = Set{} in s->union(a)->union(b)

which works because Set(S) has an operation union(Set(S)) that accepts arguments of type Set(A) and Set(B) because of the rules of conformance of collection types.

How do I invoke methods such as eContainer(), eContents(), eGet()?

Using the Pivot OCL

The Pivot OCL prototype for OCL 2.5 provides the library operations oclContainer() and oclContents(). Whether to provide an oclGet() is still under consideration.

Using the Classic OCL

These methods are EObject methods, so you need to declare that your meta-model extends EObject.

As of the Juno release, there is a Window->Preferences->OCL->Ecore and UML bindings option that allows this to be specified interactively. The final preference is the "Static instance for the implicit-root class option". Select EObject rather than None from the pull-down menu.

You can initialize the corresponding option programmatically with the following ParsingOption declaration prior to parsing.

ParsingOptions.setOption(ocl.getEnvironment(),
    ParsingOptions.implicitRootClass(ocl.getEnvironment()),
    EcorePackage.Literals.EOBJECT);

Otherwise you can just do a cast, assuming that 'http://www.eclipse.org/emf/2002/Ecore' has been imported as 'ecore'.

something.oclAsType(ecore::EObject).eClass()

(Prior to EMF 2.5.0M4 this declaration was not necessary if your meta-model explicitly inherited from an Ecore class such as EModelElement or EObject.)

How do I access unnavigable opposites in Ecore

In UML, an association that is intended only to be navigated in one direction at run-time may be drawn with a unidirectional arrow. OCL evaluation occurs at analysis-time and may navigate in both directions regardless of the arrows.

This is easy when both role names are explicitly specified. If the unnavigable role name (or multiplicity) is unspecified, an implicit opposite role name (or multiplicity) is computed from the target class name and the containment. The implicit target role name is the name of the target class. The implicit target multiplicity is [*] {ordered, unique} for a non-containment inverse and [?] for a containment inverse.

(Prior to OCL 2.3, a misunderstanding of the UML specification suggested that UML required the first letter of the class name to be converted to lowercase. This was explicitly corrected in OCL 2.3. Eclipse OCL no longer converts the class name.)

In UML, the implicit name can generally be used, but it is better to provide the opposite role names and multiplicities explicitly.

If two associations both have the same implicit opposite role name, both implicit opposites exist, but any attempt to use them will yield an ambiguous resolution error. The ambiguity vcan be resolved by using the qualified navigation syntax; you suffix the ambiguous navigation with the required opposite property name in square brackets.

In Ecore, similar problems exist and the same default inferences apply. The unnavigable opposites can be explicitly specified using EAnnotations. If you use the OCLinEcore editor, these EAnnotations are created automatically.

The Ecore opposite role name EAnotation has a Tag counterpart in EMOF.

The foregoing has been revised to describe the functionality of the Pivot OCL implementation. The Classic OCL implementation is similar but lacks the multiplicity support, see the history of this FAQ for the earlier text focused on the unresolved OCL issues.

How do I add an operation?

OCL in Primary Ecore (or UML)

The easiest way to add an operation is to extend your metamodel directly by adding an EOperation to your Ecore metamodel, putting the operation in the EClass that is most convenient to use as the self context of the operation. The OCLinEcore editor provides an Xtext editor with syntax validation for your OCL contributions to an Ecore metamodel. Alternatively you can edit the generated Java code to provide a Java implementation of your new operation.

Similarly you may add an Operation to the most convenient Class of your UML metamodel. The Papyrus editor provides an Xtext editor with syntax validation for your OCL contributions to a UML metamodel. (More details needed.)

OCL in Secondary Ecore (or UML)

If you are unable to modify your primary metamodels, you may use another metamodel, possibly a specially created metamodel in which you can place your additional operations in some arbitrary class. When you invoke these operations, you will need to use a bogus instance of this class as the self context of the operation. (More details needed.)

Complete OCL

A Complete OCL document allows you to add additional operations, properties and constraints to an existing metamodel. These additions are available for use within the Complete OCL document as if they were part of the existing metamodel although the metamodel is not actually modified. The additions cannot therefore be used outside the Complete OCL document. (More details needed.)

Extended OCL Standard Library

If you are using the Pivot version of Eclipse OCL, the OCL Standard Library is fully modelled and extensible. You may therefore define an extended library that imports the standard, or a replacement standard library. In either case you may define additional operations, iterations and properties with a binding to a Java class that implements the appropriate derived LibraryFeature API.

The OCL 'Standard' Library is supported using its own own Domain-Specific Language and associated Xtext editor. The built-in OCL Standard Library is compiled by /org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/GenerateOCLstdlibModel.mwe2 from /org.eclipse.ocl.examples.library/model/OCL-2.5.oclstdlib into /org.eclipse.ocl.examples.pivot/emf-gen/org/eclipse/ocl/examples/pivot/model/OCLstdlib.java. This compiled library is registered with the org.eclipse.ocl.examples.pivot.standard_library extension point for use under the http://www.eclipse.org/ocl/2015/Library URI. The default library is normally installed by invoking OCLstdlib.install(). Additional or replacement libraries may be compiled and registered in similar ways.

You may reference a custom library from a Complete OCL document using a library import.

library 'MyLibrary.oclstdlib'

Extension libraries may just reference a standard library.

import 'minimal.oclstdlib';
library lib : lib = 'http://minimal.oclstdlib'{
    type OclAny : AnyType {
    	operation a(elem : Boolean) : Boolean {
           post a: result = elem;
       }
    }
}

A library operation may be implemented in Java as

public static class SpacedOut extends AbstractOperation
{
	public static final SpacedOut INSTANCE = new SpacedOut();

	@Override
	public Object evaluate(@NonNull DomainEvaluator evaluator, @NonNull DomainCallExp callExp,
		@Nullable Object sourceValue, @NonNull Object... argumentValues) {
		String string = sourceValue == null? Value.INVALID_NAME : ValuesUtil.oclToString(sourceValue);
		return string;
	}
}

org.eclipse.ocl.examples.domain.library.AbstractOperation requires the most generic varargs arguments. A variety of derived classes such as AbstractBinaryOperation support more restricted arguments. The built-in library operation in org.eclipse.ocl.examples.domain.library provide many examples of implementations.

A custom library may declare the additional operation and link to its implementaion

library lib {
	type Real : PrimitiveType {
		operation spacedOut() : String => 'org.eclipse.ocl.examples.test.xtext.ImportTests$SpacedOut';
	}
}

The custom library has no nsURI of its own so it extends the prevailing standard library. It declares an additional operation for the Real type. The operation is named "spacedOut", takes no arguments and returns a String. The operation name is bound to the the implementation at org.eclipse.ocl.examples.test.xtext.ImportTests$SpacedOut.INSTANCE.

See /org.eclipse.ocl.examples.library/model/OCL-2.5.oclstdlib for many examples of operation and iteration declaration and binding to their Java counterparts.

Note that library operations may also be implemented in OCL, which can be advantageous when using the code generator where many of the null/invalid possibilities may be pruned by static data flow analysis.

operation not() : Boolean[?] precedence=UNARY => 'org.eclipse.ocl.examples.library.logical.BooleanNotOperation'
{
	body: if self.oclIsInvalid() then self
	      else if self = null then null
	      else self = false
	      endif endif;
}

Java API

You may add operations and properties directly from Java code. (More details needed.)

Can I customize error messages of OCL invariants ?

Yes. You can reformulate your OCL invariants so that you provide a more user friendly error message when an invariant fails. For more information go to Eclipse OCL help:

• Users Guide -> OCL Integration -> Custom Validation Messages (Eclipse Mars on-line help link)

Embedded OCL Issues

This section answers problems that may arise when OCL is used within other tools

Standalone

The Eclipse OSGI framework ensures that many important initializations occur automatically. If you are operating in a standalone environment, such as a JUnit test, an MWE script, or an Xtext generated compiler you must orchestrate the initialization manually.

Unable to find delegate to evaluate the '...' constraint on '...': http://www.eclipse.org/emf/2002/Ecore/OCL

This error occurs when a validation (or invocation or setting) delegate attempts to activate an OCL delegate but cannot find the required OCL registration.

Using the Pivot OCL

Solution: invoke the following in your startup code:

org.eclipse.ocl.xtext.essentialocl.EssentialOCLStandaloneSetup.doSetup();

Using the Classic OCL

Solution: invoke the following in your startup code:

String oclDelegateURI = OCLDelegateDomain.OCL_DELEGATE_URI;
EOperation.Internal.InvocationDelegate.Factory.Registry.INSTANCE.put(oclDelegateURI,
    new OCLInvocationDelegateFactory.Global());
EStructuralFeature.Internal.SettingDelegate.Factory.Registry.INSTANCE.put(oclDelegateURI,
    new OCLSettingDelegateFactory.Global());
EValidator.ValidationDelegate.Registry.INSTANCE.put(oclDelegateURI,
    new OCLValidationDelegateFactory.Global());

For an Xtext generated compiler, the above code can be placed in YourStandaloneSetup.register().

Xtext

An object may not circularly contain itself

This error arises when the root object in a model is validated twice, since validation of the root object marks itself as already validated causing the second validation to report a circular validation.

Solution: make sure that registerForImportedPackages is false in your MWE2 editor generation script.

fragment = validation.JavaValidatorFragment
{
    registerForImportedPackages = false
}

OCL Code Generation

How do I generate code from OCL constraints in Ecore?

As of EMF 2.6.0M4 and Eclipse OCL 3.0.0M6 EClassifier invariants, EOperation bodies and EStructuralFeature initial or derived values may be specified using OCL expressions embedded as Ecore annotations within an Ecore meta-model. These expressions may be evaluated either after genmodel has been used to convert your model to Java, or directly using the dynamic capabilities of EMF.

See OCL/OCLinEcore

How do I generate code from OCL constraints in UML?

See http://www.eclipse.org/modeling/mdt/uml2/docs/presentations/EclipseCon2008_LongTalk_NewFeaturesOfUML2_files/frame.htm.

OCL Editor

How do I install an editor for OCL?

Eclipse OCL Examples Editors

The Eclipse OCL project provides four Xtext-based editors. Instructions for installation may be found in http://help.eclipse.org/oxygen/topic/org.eclipse.ocl.doc/help/Tutorials.html#OCLinEcoreTutorial.

The OCLinEcore editor supports direct maintenance of OCL in an Ecore file, that may be saved as text instead.

The CompleteOCL editor supports editing OCL documents that complement Ecore meta-models

The EssentialOCL editor supports editing OCL expressions, probably within another tool.

The OCL Standard Library editor supports editing the extensible library.

These Xtext editors form part of the Pivot OCL. Their primary persistence uses the OCL textual syntax, optionally embedded in Ecore. This is substantially compatible with Classic OCL and other OCLs. However beware that not all fixes in Pivot OCL are available in the earlier Classic OCL. There are menu options to save an Abstract Syntax model that prototypes a resolution of problems in the OMG specification.

OCLinEcore editor fails to initialize due to a missing ModulemapPackage class

This problem is caused by the spurious registration of org.eclipse.jst.j2ee.internal.earcreation.modulemap.ModulemapPackage for modulemap.xmi. Since this class does not exist, any code that peruses the EMF Package registry gets a run-time exception that it probably does not handle, so a loop terminates. This occurs when Xtext starts up for OCLinEcore.

For Helios, Bug 320417 is registered against WTP, and Bug 320420 against Xtext. Both are likely to be fixed in Helios SR1. The workaround for Helios is not to install the JST plugin, typically used by the Web Page editor.

OCL Runtime

Stand-alone Tracing

Using the Classic OCL

Since the 1.1 release, Eclipse OCL has supported a stand-alone deployment. However, debug tracing has always been an all-or-nothing deal, activated by the org.eclipse.ocl.debug system property. Now, finer-grained control is available using system properties named according to the OCL plug-in's trace options. For example, to trace only evaluation of expressions (not also parsing and other activity), use -Dorg.eclipse.ocl/debug/evaluation=true.

Using the Pivot OCL

The tracing facility did not seem that useful and so it is no longer supported. You may use the OCL debugger to single step OCL expression evaluation.

OCL Thread Safety

OCL is side effect free and so concurrent operation in many threads should be possible.

However Eclipse OCL exploits EMF and so the EMF Thread Safety policies must be considered. Concurrent read and write are not supported between threads and may result in Concurrent Modification Exceptions from iterations or worse. Any code contributed to a call-back takes responsibility for the safety of any changes it makes.

Note that thread safety is very difficult to test and so the following statements may only be wishful thinking against which Bugzillas can be raised.

Analysis

Eclipse OCL does not support concurrency during expression analysis, so you may not override any of the parsing methods in order to exploit multiple processors to accelerate parsing. You may however parse multiple expressions concurrently provided you use a distinct OCL Environment for each analysis.

Pivot Meta-models

The Pivot support converts external Ecore/UML/... metamodels to a uniform Pivot representation under control of a MetamodelManager. It is intended to allow the MetamodelManager to be shared by concurrent writers and so avoid the metamodel conversion costs being incurred repeatedly. Distinct OCL environments can share a MetamodelManager.

Evaluation

Eclipse OCL should support multiple concurrent evaluations over shared models, provided no concurrent modification occurs to those models. Eclipse OCL, like EMF, requires the overall application to take responsibility for avoiding concurrency between threads that modify models from those that merely read them.

Ecore Delegates

Concurrent evaluation requires that all hidden data structures that cache context must be thread safe. This is not necessarily true for the Ecore binding, and so it is recommended that a warm-up of all queries is performed in a single thread before multiple threads are allowed to run concurrently.

Pivot Delegates

Concurrent evaluation requires that all hidden data structures that cache context must be thread safe. This is believed to be true.

Pivot Code Generation

The OCL to Java code generation eliminates the hidden caches for delegate support and instead introduces a number of statically initialized shared constants. These are believed to be thread safe.

Concurrent EnvironmentFactory instances

As of OCL 6.14.0 (2021-03) the working OCL state is maintained by a ThreadLocal in preference to the previous hierarchy of Resource/ResourceSet adapters. This solves many problems but prohibits the use of multiple concurrently active OCL working states per thread. Attempting to activate a second OCL working state will result in a Concurrent EnvironmentFactory instances inhibit local thread Executor passing message to the error log. The code then falls back to the old way of discovering the OCL working state which may result in prolific model re-analyses for allInstances() or implicit opposite navigations.

Concurrent OCL working states may be used provided OCL.activate()/deactivate() are used to ensure that only one of the OCLs is concurrectly active.

Note that while use of concurrent OCL working states on multiple threads is facilitated, such functionality is totally untested and may require significant programmer care to make it work.

See Help for more details.

UML migration

Original Names

The UML2 project's perverse design decision to make the typically Camel Case names used by modellers differently aesthetically pleasing for Ecore users has very bad consequences for OCL. OCL embedded in UML of course uses the true spelling of the names of the UML model elements. However when the OCL is exported to EAnnotations in an Ecore model, the OCL is not corrected to refer to the changed names. Parsing the OCL within Ecore fails with unresolved names. This deficiency was undetected until OCL integration in UML was taken more seriously by the Pivot OCL. The UML2 project 'solved' the problem by adding an 'originalName' EAnnotation on all ENamedElement::name features with a corrupted name. The Pivot OCL always uses this original name when it converts the loaded UML metamodel to the normalized Pivot form.

The Classic OCL has never been upgraded so users of the Classic OCL for UML risk getting parse failures, with UML not found being much the most common since the UML2Ecore conversion corrupts the name of the UML package to uml.

A common usage of UML2Ecore is to generate the Ecore source for Java generation of a static UML profile. This Ecore contains OCL embedded as Ecore EAnnotations that can be interpreted by either LPG (Classic OCL) or Pivot delegates. The embedded OCL has original name spellings and so works with Pivot OCL but may fail with the LPG (Classic OCL) delegates. If the OCL Realisation of OCL embedded within Ecore models preference is set to Generate Java Code in *Impl classes, the generated Java also contains a direct Java code generation of the OCL avoiding the need for any parsing at run-time.

To avoid the corrupt name problems of Classic OCL, users must ensure that the OCL Executor targeted by the default OCL delegate preference is set to http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot. Beware, this value is cached, so make sure you restart Eclipse after changing it. If you are testing your static profile in a nested Eclipse you need to ensure that this preference is in force in your nested Eclipse.

UML 2.4

The Juno (MDT/UML2 4.0, Eclipse OCL 4.0) is aligned with UML 2.4.1. The following differences may be apparent.

• The UML URI is "http://www.eclipse.org/uml2/4.0.0/UML" rather than "http://www.eclipse.org/uml2/3.0.0/UML"
• The UML package name is "UML" rather than "uml"
• The PrimitiveTypes package name is "PrimitiveTypes" rather than "UMLPrimitiveTypes"
• The "Standard.profile.uml" is replaced by "StandardL2.profile.uml" and "StandardL3.profile.uml"
• "UML.metamodel.uml" is the metamodel of the UML metamodel, not of a UML model.
• "UML.merged.uml" is the metamodel of a UML model.
• UML and Ecore types are now distinct: e.g. "pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#String" and "pathmap://UML_LIBRARIES/EcorePrimitiveTypes.library.uml#EString" are no longer identical. Only the EString form avoids a reference to the UML2 Types package from Ecore.

See [UML 2_4.0 Migration_Guide]

UML 2.5

The Luna (MDT/UML2 5.0, Eclipse OCL 5.0) is aligned with UML 2.5. The following differences may be apparent.

• The UML URI is "http://www.eclipse.org/uml2/5.0.0/UML" rather than "http://www.eclipse.org/uml2/4.0.0/UML"

See [UML 2_5.0 Migration_Guide]

Obsolete

The following entries involve very old versions of the software. It is strongly recommended that a more modern solution is found. But just in case they are useful, the obsolete entries are here rather than erased.

How do I workaround org.eclipse.emf.ocl deprecation in Helios and later?

The deprecated org.eclipse.emf.ocl feature and plugin were removed in the Eclipse OCL 3.0.0 release. Unfortunately some projects, notably UML2-Tools, continue to reference it. This prevents their Galileo releases being installed on Helios. A Helios release of UML-Tools has been built (26-July-2010) but its visibility from The UML2-Tools Downloads Page is not quite right yet.

[Attachment] to [Bug 318941] provides a ZIPped update site containing just enough of org.eclipse.emf.ocl to satisfy the installation requirements of org.eclipse.emf.ocl dependents.

Therefore to install e.g. UML2-Tools

• Install Eclipse OCL 3.0.0 (most conveniently as part of the Eclipse Modeling Package)
• Download org.eclipse.emf.ocl-update.zip from the [Attachment]
• Install New Software from the downloaded org.eclipse.emf.ocl-update.zip
• Download e.g. mdt-uml2tools-Update-incubation-0.9.0.zip from [UML2-Tools Downloads]
• Install New Software from the downloaded mdt-uml2tools-Update zip

Do not install anything else after UML2-Tools since org.eclipse.emf.ocl-update.zip effectively claims that Galileo and Helios are compatible undermining p2's ability to install consistent plugins.