Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

OCL 1.1 API Changes

Revision as of 15:31, 28 March 2007 by Cdamus.ca.ibm.com (Talk | contribs) (Add an example)

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 getType() : C and getName() : String operations. These operations now must be implemented by 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.

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.setEType(someType);  // note that the Variable is an ETypedElement

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);  // formerly, TypedElement had a setType() method

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).

Back to the top