OCL 1.1 API Changes

This page tracks incompatibilities from milestone to milestone in the development of new API in the MDT OCL 1.1 stream.

M5 to M6 API Incompatible Changes

As of the I200703271636 build (pre-M6), some incompatible changes are made to the API introduced in M5 to address bug 175446. The following subsections detail these changes.

org.eclipse.ocl.utilities.TypedElement<C>

The TypedElement<C> metaclass no longer defines the following properties:

• type : C
• name : String

These are replaced by setter and getter operations simulating the properties:

• getType() : C
• getName() : String
• setType(type : C)
• setName() : String

These operations are implemented on transient fields in the TypedElement subtypes in the generic Expressions package (org.eclipse.ocl.expressions). So, persistence of the generic types is not supported. In order to persist expressions, you must instantiate the metaclasses of the metamodel-specific bindings, which now must bind the OCL Expressions package as well as the Types package (as in M5). This is done for the Ecore and UML bindings of the org.eclipse.ocl.ecore and org.eclipse.ocl.uml plug-ins, respectively. Note that this requires no changes in clients that simply use the parser API, because the environment ensures that the correct bindings are instantiated.

In these plug-ins you will now see more metaclasses in the ocl.ecore and ocl.uml packages, defining the bindings for the Expressions metamodel. Likewise, the model/OCLEcore.ecore and model/OCLUML.uml models are updated to include these new bindings.

These changes should not affect most users of the OCL API, who only parse OCL expressions from text (rather than constructing them programmatically). If you are customizing your parsing and evaluation environments, the Variables that you create will now need to be of the particular metamodel binding. For example, you would do:

EClassifier someType = ... // some type for the variable
org.eclipse.ocl.ecore.Variable v = org.eclipse.ocl.ecore.EcoreFactory.eINSTANCE.createVariable();
v.setName("myVar");
v.setType(someType);

instead of:

EClassifier someType = ... // some type for the variable
org.eclipse.ocl.expressions.Variable<EClassifier, EParameter> v =
    org.eclipse.ocl.expressions.ExpressionsFactory.eINSTANCE.createVariable();
v.setName("myVar");
v.setType(someType);

org.eclipse.ocl.utilities.UMLReflection

Because the settable type and name properties have been removed from the TypedElement<C> interface, new API methods are added to the UMLReflection to set an OCL expression element's name and type:

• void setName(TypedElement<C>, String)
• void setType(TypedElement<C>, C)

This change should only affect implementers of metamodel bindings, not clients of the parser/interpreter API.

org.eclipse.ocl.utilities.TypeFactory

Due to the above changes, the TypeFactory interface is vastly expanded to provide factory methods for all of the OCL Expressions metaclasses, as the parser now requires binding-specific implementations of these (as for the types; see above). To this end, this factory interface is no longer a type factory, so it is renamed as OCLFactory. This should only affect implementers of metamodel bindings, not clients of the parser/interpreter API.

org.eclipse.ocl.ecore.EcoreFactory, org.eclipse.ocl.uml.UMLFactory

The EcoreFactory and UMLFactory interfaces no longer extend OCLFactory (the renamed TypeFactory interface). Instead, new internal classes are defined in the org.eclipse.ocl.ecore and org.eclipse.ocl.uml plug-ins to implement OCLFactory.

These changes should not affect most users of the OCL API, who only parse OCL expressions from text (rather than constructing them programmatically).