The Eclipse OCL component implements the OCL Abstract Syntax model as an EMF-based metamodel. Thus, parsed OCL expressions and constraints can be serialized, for example in XMI documents. The OCL 2.4 specification is unclear about how the serialization of expressions should look (this will be solved in the next OCL 2.5 specification), especially where references to demand-created types are concerned. This topic discusses the approach taken by the Eclipse OCL component to provide a practical solution to this problem.
OCL defines a number of template metaclasses, including the
CollectionType
metaclass and its specializations,
MessageType, and
TupleType. In all of these cases, OCL specifies that these
templates are instantiated as needed in the OCL environment, and that only one instance
of a template exists for any given combination of template arguments. For example, only one
OrderedSet(String) exists and it is created on the occasion when
it is first needed. Likewise, the
OclMessage type for invocations
of the
EModelElement::getEAnnotation(EString) operation and the
Tuple{a : String, b : EClass} type.
The problem is, that the OCL Specification does not indicate how expressions that reference
such demand-created types can be persisted, because it does not define what should own these
types. A similar problem exists for additional operations and attributes defined in OCL
via
def: expressions. The
TypeResolver
API is responsible for the demand-creation of these types and for their persistence.
Every
Environment
has a
TypeResolver that persists demand-created types and additional features. For a client that doesn’t require persistence, the
TypeResolver will create a
Resource with the dummy
ocl:// scheme (no resource factory is provided for this scheme).
A client that does require persistence of OCL expressions and these demand-created elements
should provide a specific resource in which to store them, either via the
OCL
class’s
newInstance(EnvironmentFactory, Resource) factory method or via
the
EnvironmentFactory
interface’s
load(Resource) method.
Resource modelResource = getResourceSet().getResource(
URI.createPlatformResourceURI("/models/My.ecore", true), true);
// persist demand-created types etc. in my model resource
OCL<?, EClassifier, ?, ?, ?, ?, ?, ?, ?, Constraint, EClass, EObject> ocl;
ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE, myResource);
// use the OCL to parse constraints, store them in the Ecore model,
// and save everything together in one resource for a consistent,
// self-contained OCL environment
...
The
AbstractTypeResolver
class creates packages in which to store the different elements that it creates: collection types, message types, tuple types, and additional operations and attributes. These last are owned by classes that “shadow” the classifiers in which context they are defined, in
the manner by which the OCL specification’s adaptation for EMOF indicates that operations
are to be “owned” by EMOF
DataType s.
An environment implementation can customize the way these demand-created elements are
stored, by choosing different packages or using some other strategy altogether. Or, using
the default
TypeResolver implementation, a client of the OCL
parser can find the demand-created objects in the resolver’s resource and relocate them
as needed.