blob: 3add9695f73796d91085947c33ded01510a82fca [file] [log] [blame]
<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>OCL Relationship to Metamodels</title>
<link href="book.css" rel="stylesheet" type="text/css">
<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
<link rel="home" href="index.html" title="OCL Documentation">
<link rel="up" href="ProgrammersGuide.html" title="Classic Ecore/UML Programmers Guide">
<link rel="prev" href="ParsingDocuments.html" title="Parsing OCL Documents">
<link rel="next" href="ContentAssistSupport.html" title="Content Assist Support">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">OCL Relationship to Metamodels</h1>
<div class="section" title="OCL Relationship to Metamodels">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both">
<a name="TargetMetamodels"></a>OCL Relationship to Metamodels</h2>
</div>
</div>
</div>
<p>The OCL implementation provides support for models defined using either the
Ecore or the UML metamodel (as implemented by the Eclipse EMF and UML2 projects),
and an
<a class="link" href="AdvancedMetamodelBindings.html" title="Creating Metamodel Bindings">extensibility API</a> that allows
additional EMF-based metamodels to be plugged in.
</p>
<div class="blockquote">
<blockquote class="blockquote">
<p>
The direct and indirect coupling of the Ecore and UML2 meta-models to Ecore makes exact compliance with the OMG specification very difficult, particularly in the area of reflection. Eclipse OCL is therefore migrating to a new potentially 100% OMG compliant Pivot metamodel that hides the differencess between OMG&rsquo;s UML and EMOF and Eclipse&rsquo;s UML and Ecore. The Pivot binding is described in the
<a class="link" href="PivotProgrammersGuide.html" title="Unified or Pivot Programmers Guide">Pivot Programmers Guide</a>.
</p>
</blockquote>
</div>
<p>
The OCL API implements support for different target metamodels via the
<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/EnvironmentFactory.html" target="_new">
<code class="code">EnvironmentFactory</code>
</a> interface. An implementation of this interface binds the metamodel&rsquo;s metaclasses to the generic type parameters of the
<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/OCL.html" target="_new">
<code class="code">OCL</code>
</a> class. The metamodel-specific
<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/Environment.html" target="_new">
<code class="code">Environment</code>
</a> implementation constructed by this factory implements the reflection capability required by OCL to discover the elements of the model being constrained and the relationships between them.
</p>
<div class="section" title="The Ecore Metamodel Binding">
<div class="titlepage">
<div>
<div>
<h3 class="title">
<a name="TheEcoreMetamodelBinding"></a>The Ecore Metamodel Binding</h3>
</div>
</div>
</div>
<p>An OCL binding for the Ecore metamodel is provided by the
<code class="code">org.eclipse.ocl.ecore</code> plug-in. It is best suited to parsing and evaluating OCL constraints on Ecore models. Evaluation of constraints is supported on instances of the EMF-generated Java API (Ecore as the source for the genmodel) and on dynamic EObjects.
</p>
<p>As is illustrated by most of the examples in this documentation, the Ecore binding is provided by the
<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/EcoreEnvironmentFactory.html" target="_new">
<code class="code">EcoreEnvironmentFactory</code>
</a> class. By default, the Ecore environment uses the static
<code class="code">EPackage</code> registry to look up package names. It can also be supplied with an alternative package registry (for example, one local to a
<code class="code">ResourceSet</code>) but it will always use the static registry as a backup. Aside from the package registry, the Ecore environment factory maintains no state. So, when the shared registry is to be used, the static
<code class="code">EcoreEnvironmentFactory.INSTANCE</code> is most practical.
</p>
<p>The Ecore binding for OCL provides the following capabilities, reflecting the subset of Ecore&rsquo;s modeling constructs with respect to UML:</p>
<table id="N14A3D">
<tr>
<th>Capability</th>
<th>Parse</th>
<th>Evaluate</th>
</tr>
<tr>
<td>Classifier invariant constraints</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Operation precondition and postcondition constraints and body conditions</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>Property constraints (initial-value and derivation)</td>
<td>Y</td>
<td>Y*</td>
</tr>
<tr>
<td>Attribute and operation definitions (def: expressions)</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Package context declaration</td>
<td>Y</td>
<td>n/a</td>
</tr>
<tr>
<td>Basic values and types, mapped from the standard EDataTypes to OCL&rsquo;s primitive types</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Collection types</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Navigation of attributes and references</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Operation invocation</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Iteration expressions (all standard iterators)</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Let expressions</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>If expressions</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Tuples</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Message expressions, including unspecified values</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>Operations predefined by OCL: allInstances()</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Operations predefined by OCL: oclIsKindOf(), oclIsTypeOf(), oclAsType()</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Operations predefined by OCL: oclIsNew()</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>@pre expressions</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>* derivation only</td>
</tr>
</table>
<p>
<span class="bold"><strong>Ecore metamodel capability matrix</strong></span>
</p>
<p>Because Ecore does not define analogues of some of the UML metaclasses required by the OCL Abstract Syntax Model, the Ecore binding defines these on its behalf, in the
<code class="code">platform:/plugin/org.eclipse.ocl.ecore/model/OCLEcore.ecore</code> metamodel. These include:
</p>
<div class="itemizedlist">
<ul class="itemizedlist" type="disc">
<li class="listitem">
<p>
<code class="code">Constraint</code>: the model of an OCL constraint (when the
<code class="code">language</code> is OCL)
</p>
</li>
<li class="listitem">
<p>
<code class="code">CallOperationAction</code>: used in the model of message expressions
</p>
</li>
<li class="listitem">
<p>
<code class="code">SendSignalAction</code>: used in the model of message expressions
</p>
</li>
<li class="listitem">
<p>
<code class="code">ExpressionInOCL</code>: it is this metaclass&rsquo;s general class
<code class="code">OpaqueExpression</code> that Ecore does not define. It is elided in the Ecore binding
</p>
</li>
<li class="listitem">
<p>
<code class="code">State</code>: Ecore provides no behavior modeling capabilities. The Ecore binding simply substitutes
<code class="code">EObject</code>
</p>
</li>
</ul>
</div>
<p>For applications that work exclusively with the Ecore binding for OCL, the
<code class="code">org.eclipse.ocl.ecore</code> package defines a subclass of the
<code class="code">OCL</code> class that supplies all of the generic type parameter bindings to simplify typing (in the absence of type aliasing in Java). It also provides Ecore-specific convenience factory methods for the
<code class="code">OCL</code>, itself, and narrows the return type of the factory methods for the
<code class="code">OCLHelper</code> and
<code class="code">Query</code> interfaces. These specialized interfaces likewise supply the generic type parameter bindings for Ecore.
</p>
</div>
<div class="section" title="The UML Metamodel Binding">
<div class="titlepage">
<div>
<div>
<h3 class="title">
<a name="TheUMLMetamodelBinding"></a>The UML Metamodel Binding</h3>
</div>
</div>
</div>
<p>An OCL binding for the UML metamodel is provided by the
<code class="code">org.eclipse.ocl.uml</code> plug-in. It is best suited to parsing and evaluating OCL constraints on UML models. Evaluation of constraints is supported on instances of the UML2-generated Java API (UML as the source for the genmodel), on dynamic EObjects (using an Ecore model created by the UML-to-Ecore converter), and on
<code class="code">InstanceSpecification</code> elements in the UML model.
</p>
<p>The UML binding is provided by the
<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/uml/UMLEnvironmentFactory.html" target="_new">
<code class="code">UMLEnvironmentFactory</code>
</a> class. By default, the UML environment factory and all of the environment contexts that it creates use a private
<code class="code">ResourceSet</code> to look up the corresponding UML model(s) against which OCL constraints are parsed.
</p>
<div class="itemizedlist">
<ul class="itemizedlist" type="disc">
<li class="listitem">
<p>It is the client&rsquo;s responsibility to ensure that the UML model is loaded in the resource set used by the UML environment factory instance.</p>
</li>
</ul>
</div>
<p>The UML environment factory can alternatively be initialized with a resource set of the client&rsquo;s choosing. Ordinarily, the UML environment uses its resource set&rsquo;s local
<code class="code">EPackage</code> registry to look up EMF-generated
<code class="code">EPackage</code> names corresponding to UML models. A custom package registry may be provided by the client if necessary.
</p>
<p>The UML binding for OCL provides the following capabilities:</p>
<table id="N14BF2">
<tr>
<th>Capability</th>
<th>Parse</th>
<th>Evaluate</th>
</tr>
<tr>
<td>Classifier invariant constraints</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Operation precondition and postcondition constraints and body conditions</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>Property constraints (initial-value and derivation)</td>
<td>Y</td>
<td>Y*</td>
</tr>
<tr>
<td>Attribute and operation definitions (def: expressions)</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Package context declaration</td>
<td>Y</td>
<td>n/a</td>
</tr>
<tr>
<td>Basic values and types</td>
<td>Y</td>
<td>Y+</td>
</tr>
<tr>
<td>Collection types</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Operation invocation</td>
<td>Y</td>
<td>Y-</td>
</tr>
<tr>
<td>Navigation of attributes and references</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Navigation of non-navigable association ends (including those that are owned by the association)</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Qualified association end navigation</td>
<td>Y</td>
<td>Y=</td>
</tr>
<tr>
<td>Navigation to association classes, including source qualifiers</td>
<td>Y</td>
<td>Y=</td>
</tr>
<tr>
<td>Iteration expressions (all standard iterators)</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Let expressions</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>If expressions</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Tuples</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Message expressions, including unspecified values</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>Operations predefined by OCL: allInstances()</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Operations predefined by OCL: oclIsKindOf(), oclIsTypeOf(), oclAsType()</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>Operations predefined by OCL: oclIsInState()</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>Operations predefined by OCL: oclIsNew()</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>@pre expressions</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>* derivation only</td>
</tr>
<tr>
<td>+ OCL defines the Real primitive type that is missing from UML, but not a LiteralReal</td>
</tr>
<tr>
<td>- with InstanceSpecifications, only where body constraints are defined</td>
</tr>
<tr>
<td>= only with InstanceSpecifications</td>
</tr>
</table>
<p>
<span class="bold"><strong>UML metamodel capability matrix</strong></span>
</p>
<p>A special case of the UML environment&rsquo;s support for dynamic EObjects, mentioned
above, is stereotype applications. The Eclipse UML2 component uses dynamic
EMF in the implementation of stereotype applications, by converting UML
<code class="code">Profile</code> s to
<code class="code">EPackage</code> s.
Constraints parsed in the context of a UML
<code class="code">Stereotype</code>
can be evaluated on applications (instances) of that stereotype or on model
elements to which the stereotype is applied. This applies only to UML models,
themselves, as instances of the UML metamodel (stereotyping is only available
in the UML metamodel).
</p>
<p>For applications that work exclusively with the UML binding for OCL, the
<code class="code">org.eclipse.ocl.uml</code> package defines a subclass of
the
<code class="code">OCL</code> class that supplies all of the generic type
parameter bindings to simplify typing (in the absence of type aliasing in Java).
It also provides UML-specific convenience factory methods for the
<code class="code">OCL</code>, itself, and narrows the return type of the factory
methods for the
<code class="code">OCLHelper</code> and
<code class="code">Query</code> interfaces. These specialized interfaces likewise
supply the generic type parameter bindings for UML.
</p>
</div>
</div>
</body>
</html>