doc/org.eclipse.ocl.doc/html/ocl.html - ocl/org.eclipse.ocl - Git at Google

 <html>
 <head>
 <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
 <title>OCL Documentation</title>
 <link href="book.css" rel="stylesheet" type="text/css">
 <meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
 </head>
 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
 <div class="book" title="OCL Documentation">
 <div class="titlepage">
 <div>
 <div>
 <h1 class="title">
 <a name="N10001"></a>OCL Documentation</h1>
 </div>
 </div>
 <hr>
 </div>
 <div class="toc">
 <p>
 <b>Table of Contents</b>
 </p>
 <dl>
 <dt>
 <span class="chapter"><a href="#OverviewandGettingStarted">1. Overview and Getting Started</a></span>
 </dt>
 <dd>
 <dl>
 <dt>
 <span class="section"><a href="#WhatisOCL">What is OCL?</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#HowDoesItWork">How Does It Work?</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#EclipseOCLisExtensible">Eclipse OCL is Extensible</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#WhoUsesOCLandEclipseOCL">Who Uses OCL and Eclipse OCL?</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#WhoisBehindEclipseOCL">Who is Behind Eclipse OCL?</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#GettingStarted">Getting Started</a></span>
 </dt>
 </dl>
 </dd>
 <dt>
 <span class="chapter"><a href="#UsersGuide">2. Users Guide</a></span>
 </dt>
 <dd>
 <dl>
 <dt>
 <span class="section"><a href="#EclipseOCLs">The two Eclipse OCLs</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#EssentialOCL">The Essential OCL Language</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OCLinEcore">The OCLinEcore Language</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#CompleteOCL">The Complete OCL Language</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OCLstdlib">The OCL Standard Library Language</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Editors">Editors</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#NatureAndBuilder">OCL Nature and Builder Auto-Validation</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#InteractiveOCL">Console</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#ValidityView">Validity View (new in Luna)</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Debugger">Debugger (new in Luna)</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Integration">OCL Integration</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OCLinPapyrus">OCL in UML (using Papyrus)</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OCLExamplesforUML">OCL Constraint Examples for UML (using Papyrus)</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#UserInterface">User Interface</a></span>
 </dt>
 </dl>
 </dd>
 <dt>
 <span class="chapter"><a href="#StandardLibrary">3. The OCL Standard Library</a></span>
 </dt>
 <dd>
 <dl>
 <dt>
 <span class="section"><a href="#Precedences">
 				<span class="bold"><strong>Precedences</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Bag">
 				<span class="bold"><strong>
 					<code class="code">Bag(T)</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Boolean">
 				<span class="bold"><strong>
 					<code class="code">Boolean</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Class">
 				<span class="bold"><strong>
 					<code class="code">Class</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Collection">
 				<span class="bold"><strong>
 					<code class="code">Collection(T)</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Enumeration">
 				<span class="bold"><strong>
 					<code class="code">Enumeration</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#EnumerationLiteral">
 				<span class="bold"><strong>
 					<code class="code">EnumerationLiteral</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Integer">
 				<span class="bold"><strong>
 					<code class="code">Integer</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Map">
 				<span class="bold"><strong>
 					<code class="code">Map(K, V)</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclAny">
 				<span class="bold"><strong>
 					<code class="code">OclAny</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclComparable">
 				<span class="bold"><strong>
 					<code class="code">OclComparable</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclElement">
 				<span class="bold"><strong>
 					<code class="code">OclElement</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclEnumeration">
 				<span class="bold"><strong>
 					<code class="code">OclEnumeration</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclInvalid">
 				<span class="bold"><strong>
 					<code class="code">OclInvalid</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclLambda">
 				<span class="bold"><strong>
 					<code class="code">OclLambda</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclMessage">
 				<span class="bold"><strong>
 					<code class="code">OclMessage</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclSelf">
 				<span class="bold"><strong>
 					<code class="code">OclSelf</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclState">
 				<span class="bold"><strong>
 					<code class="code">OclState</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclStereotype">
 				<span class="bold"><strong>
 					<code class="code">OclStereotype</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclSummable">
 				<span class="bold"><strong>
 					<code class="code">OclSummable</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclTuple">
 				<span class="bold"><strong>
 					<code class="code">OclTuple</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclType">
 				<span class="bold"><strong>
 					<code class="code">OclType</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OclVoid">
 				<span class="bold"><strong>
 					<code class="code">OclVoid</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OrderedCollection">
 				<span class="bold"><strong>
 					<code class="code">OrderedCollection(T)</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OrderedSet">
 				<span class="bold"><strong>
 					<code class="code">OrderedSet(T)</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Real">
 				<span class="bold"><strong>
 					<code class="code">Real</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Sequence">
 				<span class="bold"><strong>
 					<code class="code">Sequence(T)</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Set">
 				<span class="bold"><strong>
 					<code class="code">Set(T)</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#State">
 				<span class="bold"><strong>
 					<code class="code">State</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#String">
 				<span class="bold"><strong>
 					<code class="code">String</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Type">
 				<span class="bold"><strong>
 					<code class="code">Type</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#UniqueCollection">
 				<span class="bold"><strong>
 					<code class="code">UniqueCollection(T)</code>
 				</strong></span>
 			</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#UnlimitedNatural">
 				<span class="bold"><strong>
 					<code class="code">UnlimitedNatural</code>
 				</strong></span>
 			</a></span>
 </dt>
 </dl>
 </dd>
 <dt>
 <span class="chapter"><a href="#Tutorials">4. Tutorials</a></span>
 </dt>
 <dd>
 <dl>
 <dt>
 <span class="section"><a href="#OCLinEcoreTutorial">OCLinEcore tutorial</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#CompleteOCLTutorial">Complete OCL tutorial</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#SafeNavigationTutorial">Safe navigation tutorial</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#CodeGenerationTutorial">Code Generation tutorial</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#DebuggerTutorial">Debugger tutorial</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#ValidationTutorial">Validation tutorial</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OCLInterpreterTutorial">Working with Classic OCL</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Extensions">Extensions (in the Unified/Pivot OCL prototype)</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Installation">Installing the Eclipse OCL Examples and Editors</a></span>
 </dt>
 </dl>
 </dd>
 <dt>
 <span class="chapter"><a href="#Examples">5. Examples</a></span>
 </dt>
 <dd>
 <dl>
 <dt>
 <span class="section"><a href="#RoyalAndLoyalExample">Royal and Loyal Example Project</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#EmptyExample">Empty Example Project</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OCLinEcoreTutorialExampleProject">OCLinEcore Tutorial Example Project</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#CompleteOCLTutorialExampleProject">Complete OCL Tutorial Example Project</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#OCLInterpreterExample">OCL Interpreter Example</a></span>
 </dt>
 </dl>
 </dd>
 <dt>
 <span class="chapter"><a href="#ProgrammersGuide">6. Classic Ecore/UML Programmers Guide</a></span>
 </dt>
 <dd>
 <dl>
 <dt>
 <span class="section"><a href="#ParsingConstraints">Parsing Constraints and Queries</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#EvaluatingConstraints">Evaluating Constraints and Queries</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#ParsingDocuments">Parsing OCL Documents</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#TargetMetamodels">OCL Relationship to Metamodels</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#ContentAssistSupport">Content Assist Support</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#AbstractSyntax">OCL Abstract Syntax Model</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#CustomizingtheEnvironment">Customizing the Environment</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Persistence">OCL Persistence</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#AdvancedMetamodelBindings">Creating Metamodel Bindings</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#ImpactAnalyzer">Incrementally Re-Evaluating OCL Expressions Using the Impact Analyzer</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Delegates">Delegates</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Standalone">Ecore/UML Standalone Configuration</a></span>
 </dt>
 </dl>
 </dd>
 <dt>
 <span class="chapter"><a href="#PivotProgrammersGuide">7. Unified or Pivot Programmers Guide</a></span>
 </dt>
 <dd>
 <dl>
 <dt>
 <span class="section"><a href="#Validators">Validators</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#PivotEvaluator">The Pivot Evaluator</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#PivotStandalone">Pivot Standalone Configuration</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#PivotThreadSafety">Pivot Thread Safety</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#PivotParsingConstraints">Parsing Constraints and Queries</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#PivotEvaluatingConstraints">Evaluating Constraints and Queries</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#PivotParsingDocuments">Parsing OCL Documents</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#PivotMetamodels">OCL Relationship to Metamodels</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Pivot-Ids">Ids</a></span>
 </dt>
 </dl>
 </dd>
 <dt>
 <span class="chapter"><a href="#APIReference">8. API Reference</a></span>
 </dt>
 <dd>
 <dl>
 <dt>
 <span class="section"><a href="#Javadoc">Javadoc</a></span>
 </dt>
 <dt>
 <span class="section"><a href="#Extensionpoints">Extension points</a></span>
 </dt>
 </dl>
 </dd>
 <dt>
 <span class="chapter"><a href="#BuildingtheOCLProject">9. Building the OCL Project</a></span>
 </dt>
 <dd>
 <dl>
 <dt>
 <span class="section"><a href="#GenAnnotations">GenModel GenAnnotations</a></span>
 </dt>
 </dl>
 </dd>
 <dt>
 <span class="appendix"><a href="#glossary">A. Glossary</a></span>
 </dt>
 </dl>
 </div>
 <div class="chapter" title="Chapter&nbsp;1.&nbsp;Overview and Getting Started">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title">
 <a name="OverviewandGettingStarted"></a>Chapter&nbsp;1.&nbsp;Overview and Getting Started</h2>
 </div>
 </div>
 </div>
 <p>For a quick demonstration of OCL enrichment of an Ecore meta-model with computed constraints go to
 			<a class="link" href="#GettingStarted" title="Getting Started">Getting Started</a>.
 		</p>
 <p>A PDF version of this documentation is available at
 			<a class="ulink" href="http://download.eclipse.org/ocl/doc/6.6.0/ocl.pdf" target="_new">OCL 6.6.0 Documentation</a>.
 		</p>
 <div class="section" title="What is OCL?">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="WhatisOCL"></a>What is OCL?</h2>
 </div>
 </div>
 </div>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <span class="emphasis"><em>EMF is Modeled Structure</em></span>

 </p>
 </li>
 </ul>
 </div>
 <p>The Eclipse Modeling Framework (
 				<em class="glossterm">EMF</em>) supports the definition of structural meta-models and the subsequent use of models conforming to these meta-models. EMF also supports generating of Java code to represent the meta-models. Additional Java code can be provided to add behavior to the structural meta-models.
 			</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <span class="emphasis"><em>OCL is EMF and Modeled Behavior</em></span>

 </p>
 </li>
 </ul>
 </div>
 <p>

 <em class="glossterm">OCL</em> provides a modeling language that allows the behavior to be embedded within the structural meta-models or provided as a complement to those meta-models. As a modeling language, OCL understands the models and so OCL code is much more compact than the equivalent Java. OCL code can be statically checked, whereas the corresponding Java code often uses reflection and so cannot be checked.
 			</p>
 <p>Eclipse OCL is an implementation of the OMG OCL 2.4 specification for use with Ecore and UML meta-models.</p>
 </div>
 <div class="section" title="How Does It Work?">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="HowDoesItWork"></a>How Does It Work?</h2>
 </div>
 </div>
 </div>
 <p>OCL is a programming language, so you will want to edit it, execute it and debug it.</p>
 <div class="section" title="Editing">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Editing"></a>Editing</h3>
 </div>
 </div>
 </div>
 <p>Eclipse OCL supports entry of semantically checked OCL expressions</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>embedded within Ecore using the
 							<a class="link" href="#OCLinEcore" title="The OCLinEcore Language">OCLinEcore</a> editor
 						</p>
 </li>
 <li class="listitem">
 <p>as complementary documents using the
 							<a class="link" href="#CompleteOCL" title="The Complete OCL Language">Complete OCL</a> editor
 						</p>
 </li>
 <li class="listitem">
 <p>interactive entry and evaluation using the
 							<a class="link" href="#InteractiveOCL" title="Console">Interactive OCL</a> console.
 						</p>
 </li>
 <li class="listitem">
 <p>programmatic entry and evaluation using the
 							<a class="link" href="#ProgrammersGuide" title="Chapter&nbsp;6.&nbsp;Classic Ecore/UML Programmers Guide">Java API</a>

 </p>
 </li>
 </ul>
 </div>
 <p>EMF supports entry of unchecked OCL</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>embedded within Ecore using the Sample Ecore Editor properties view</p>
 </li>
 </ul>
 </div>
 <p>Eclipse UML supports entry of unchecked OCL</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>embedded within UML OpaqueExpressions using the UML Model Editor properties view</p>
 </li>
 </ul>
 </div>
 <p>

 <a class="link" href="#OCLinPapyrus" title="OCL in UML (using Papyrus)">Papyrus</a> supports entry of semantically checked OCL expressions
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>embedded within UML OpaqueExpressions using the
 							<a class="link" href="#EssentialOCL" title="The Essential OCL Language">Essential OCL</a> editor
 						</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Execution">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Execution"></a>Execution</h3>
 </div>
 </div>
 </div>
 <p>Eclipse OCL supports OCL execution</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>interactive entry and evaluation using the
 							<a class="link" href="#InteractiveOCL" title="Console">Interactive OCL</a> console.
 						</p>
 </li>
 <li class="listitem">
 <p>programmatic entry and evaluation using the
 							<a class="link" href="#ProgrammersGuide" title="Chapter&nbsp;6.&nbsp;Classic Ecore/UML Programmers Guide">Java API</a>

 </p>
 </li>
 </ul>
 </div>
 <p>EMF support for generated models enables OCL execution of</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>constraints, operation bodies and property initializers using the
 							<a class="link" href="#ProgrammersGuide" title="Chapter&nbsp;6.&nbsp;Classic Ecore/UML Programmers Guide">Java API</a>

 </p>
 </li>
 </ul>
 </div>
 <p>EMF support for dynamic models enables OCL execution of</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>constraints using the
 							<a class="link" href="#ValidationDelegate" title="Validation Delegates">Validation Delegate</a> API
 						</p>
 </li>
 <li class="listitem">
 <p>operation bodies using the
 							<a class="link" href="#InvocationDelegate" title="Invocation Delegates">Invocation Delegate</a> API
 						</p>
 </li>
 <li class="listitem">
 <p>property initializers using the
 							<a class="link" href="#SettingDelegate" title="Setting Delegates">Setting Delegate</a> API
 						</p>
 </li>
 <li class="listitem">
 <p>queries using the
 							<a class="link" href="#QueryDelegate" title="Query Delegates">Query Delegate</a> API
 						</p>
 </li>
 </ul>
 </div>
 <p>All OCL execution is normally interpreted and starts from the OCL source text (Concrete Syntax). There is therefore a first time parsing overhead to create the compiled form (Abstract Syntax). The compiled form is cached to avoid repeated parsing costs. </p>
 <p>Altenatively the direct Java code generator may be used as described in the
 					<a class="link" href="#CodeGenerationTutorial" title="Code Generation tutorial">Code Generator Tutorial</a>.
 				</p>
 </div>
 <div class="section" title="Debugging">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Debugging"></a>Debugging</h3>
 </div>
 </div>
 </div>
 <p>Since OCL is used embedded in a larger environment, debugging is not easy to provide for OCL in isolation. The
 					<a class="link" href="#Debugger" title="Debugger (new in Luna)">OCL debugger</a> provides a variety of launch mechanisms that enable re-use of model element and/or constraint selections.
 				</p>
 <p>Alternatively the following approaches may be useful within other toosl</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>use the hover-text in the semantic editor to understand the expression types</p>
 </li>
 <li class="listitem">
 <p>use the quick-fixes in the semantic editor for possible corrections</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>if the same fix is suggested more than once, try restarting the editor</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>use the completion assist in the semantic editor for possible syntaxes</p>
 </li>
 <li class="listitem">
 <p>use intermediate invariants to check partial results</p>
 </li>
 <li class="listitem">
 <p>use the optional explanation messages for an invariant to provide a 'printf'</p>
 </li>
 <li class="listitem">
 <p>use the
 							<a class="link" href="#InteractiveOCL" title="Console">Interactive Xtext OCL</a> console to practice a problematic expression on a model
 						</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Testing">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Testing"></a>Testing</h3>
 </div>
 </div>
 </div>
 <p>Once again, since OCL is used embedded in a larger environment, testing is not easy to provide for OCL in isolation. The following approaches may be useful.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>use the
 							<a class="link" href="#InteractiveOCL" title="Console">Interactive Xtext OCL</a> console to practice sub-expressions of a problematic expression on a model
 						</p>
 </li>
 </ul>
 </div>
 <p>The Eclipse OCL development uses an extended JUnit framework that allows the Eclipse OCL code to be tested by assertions such as:</p>
 <div class="literallayout">
 <p>
 <code class="code">assertQueryInvalid(null,&nbsp;"let&nbsp;b&nbsp;:&nbsp;Boolean&nbsp;=&nbsp;null&nbsp;in&nbsp;true&nbsp;and&nbsp;b");<br>
 assertQueryResults(null,&nbsp;"Set{'b'}",&nbsp;"Set{'a',&nbsp;'b',&nbsp;'c'}&nbsp;-&nbsp;Set{'c',&nbsp;'a'}");<br>

 </code>
 </p>
 </div>
 <p>(The null first argument may be a context object.)</p>
 <p>See the org.eclipse.ocl.examples.xtext.tests plugin for further details.</p>
 </div>
 </div>
 <div class="section" title="Eclipse OCL is Extensible">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="EclipseOCLisExtensible"></a>Eclipse OCL is Extensible</h2>
 </div>
 </div>
 </div>
 <p>The Classic Eclipse OCL is used as a component in a variety of other Eclipse projects such as Acceleo, BIRT, GMF, Modisco, QVTo. Ecore models are used directly, which leads to some internal difficulties.</p>
 <p>The new Unified Eclipse OCL exploits Xtext and uses Ecore models indirectly via a UML-aligned Pivot models. This provides a choice between the classic APIs that offer limited forward functionality, and the new APIs that some of which are promoted to non-experimental form in the Mars release. Many remain experimental and internal.</p>
 <p>The new code already offers a fully modeled Standard Library that can be extended or replaced. The new OCL grammars are extended internally from Essential OCL to OCLinEcore or Complete OCL, and externally to QVT Core and QVT Relational. The associated Concrete Syntax to Abstract Syntax mapping is not yet model-driven and so harder to extend.</p>
 <p>Full model-driven extensibility is planned for a future release.</p>
 </div>
 <div class="section" title="Who Uses OCL and Eclipse OCL?">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="WhoUsesOCLandEclipseOCL"></a>Who Uses OCL and Eclipse OCL?</h2>
 </div>
 </div>
 </div>
 <p>The OCL specification is defined by the
 				<em class="glossterm">OMG</em>. It originally evolved as part of
 				<em class="glossterm">UML</em> where it is used for the detailed mathematical aspects that are not appropriate for graphical exposition. OCL 2.0 was split off from UML 2.0 in recognition of its greater utility.
 			</p>
 <p>Within the OMG context, OCL has been re-used as the foundation for the MOFM2T(Model to Text) Model-to-Text transformation language and the
 				<em class="glossterm">QVT</em> Model-to-Model transformation language. Eclipse implementations of these are available as the Acceleo and QVT Operational projects.
 			</p>
 <p>Eclipse OCL is an implementation of the OCL specification for use in conjunction with EMF and in particular Ecore and UML2 meta-models. As the behavioral extension for EMF, Eclipse OCL can be used wherever EMF can.</p>
 <p>As a specification language, OCL is frequently used when the behavior of models is formally specified.</p>
 <p>The use of OCL as an execution language has been hindered by the quality of tool support. Beyond the research domain, many usages have been proprietary. One advanced proprietary usage at SAP has been contributed to Eclipse OCL and is available as the
 				<a class="link" href="#ImpactAnalyzer" title="Incrementally Re-Evaluating OCL Expressions Using the Impact Analyzer">Impact Analyzer</a>. This supports strategic planning of run-time notifications so that derived model properties can be updated efficiently in response to a change to a model. Thousand-fold speed improvements are achievable on large models using OCL rather than Java because OCL has a formal model-based semantics that is amenable to analysis.
 			</p>
 <p>The use of OCL in general is eased by the provision of good editors exploiting Xtext to provide comprehensive semantic feedback in a familiar editing style.</p>
 <p>The use of OCL for execution is enhanced by providing direct Java code generation for OCL embedded in models. This should alleviate many of the performance concerns for interpreted execution of embedded OCL.</p>
 <p>Debugging of OCL execution is now possible using the OCL debugger and the OCL Console can be used for OCL experimentation.</p>
 </div>
 <div class="section" title="Who is Behind Eclipse OCL?">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="WhoisBehindEclipseOCL"></a>Who is Behind Eclipse OCL?</h2>
 </div>
 </div>
 </div>
 <p>Eclipse OCL is an Open Source project. The original code for OCL 1.x was contributed by IBM. It has evolved to support OCL 2.x under the auspices of Eclipse.</p>
 <p>There is now a significant personnel and corporate overlap between the Eclipse OCL committers and the OMG OCL
 				<em class="glossterm">RTF</em> and so Eclipse OCL is pioneering solutions to many of the under-specification problems in the OCL specification.
 			</p>
 <p>You can expect future changes in OMG OCL to have an implementation in Eclipse OCL to demonstrate their viability. It is likely that the next version of the OCL specification will use Eclipse OCL and M2T(Model to Text) tooling to eliminate inconsistencies. Eclipse OCL is currently in use to check that the OCL used in the UML 2.5 specification is syntactically and semantically correct.</p>
 <p>Direct tooling of the UML 2.5 and OCL 2.5 specifications for a future Eclipse release may demonstrate that the OCL aspects of the specifications is also functionally consistent.</p>
 </div>
 <div class="section" title="Getting Started">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="GettingStarted"></a>Getting Started</h2>
 </div>
 </div>
 </div>
 <p>For a very quick demonstration of OCL, you may follow this very abbreviated version of the
 				<a class="link" href="#OCLinEcoreTutorial" title="OCLinEcore tutorial">OCLinEcore tutorial</a>, where you can find
 				<a class="link" href="#Installation" title="Installing the Eclipse OCL Examples and Editors">Installation</a> instructions. Once you have the OCL Examples and Editors feature installed you may follow these instructions to get an insight into the capabilities of OCL and the Eclipse OCL tooling.
 			</p>
 <p>Invoke
 				<span class="bold"><strong>File-&gt;New-&gt;Project...</strong></span> then select
 				<span class="bold"><strong>Examples</strong></span> then
 				<span class="bold"><strong>OCL (Object Constraint Language) Plugins</strong></span> then
 				<span class="bold"><strong>OCLinEcore Tutorial</strong></span> and
 				<span class="bold"><strong>Finish</strong></span> to create a small example project called
 				<span class="bold"><strong>org.eclipse.ocl.examples.project.oclinecoretutorial</strong></span>. It contains
 			</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <span class="bold"><strong>model/Tutorial.ecore</strong></span> - a small Library meta-model
 					</p>
 </li>
 <li class="listitem">
 <p>

 <span class="bold"><strong>model/Tutorial.xmi</strong></span> - an even smaller Library model
 					</p>
 </li>
 <li class="listitem">
 <p>

 <span class="bold"><strong>model/Tutorial.genmodel</strong></span> - a gebnerator for Java code
 					</p>
 </li>
 </ul>
 </div>
 <p>Select
 				<span class="bold"><strong>model/Tutorial.ecore</strong></span> and use the right button to invoke
 				<span class="bold"><strong>Open With-&gt;OCLinEcore Editor</strong></span>. This gives you a textual view of the Ecore file with embedded OCL invariants such as the Book constraint
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">invariant&nbsp;SufficientCopies:<br>
 &nbsp;&nbsp;library.loans-&gt;select((book&nbsp;=&nbsp;self))-&gt;size()&nbsp;&lt;=&nbsp;copies;<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>This invariant is named SufficientCopies. It </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>navigates from the implicit self (a Book)</p>
 </li>
 <li class="listitem">
 <p>via the library </p>
 </li>
 <li class="listitem">
 <p>to its loans which it searches</p>
 </li>
 <li class="listitem">
 <p>to select those loans that satisfy the predicate</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>loaned book is equal to the self Book</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>the size (number) of loans is computed</p>
 </li>
 <li class="listitem">
 <p>and compared to the number of copies of the self Book</p>
 </li>
 </ul>
 </div>
 <p>The invariant is satisfied if it evaluates true; i.e. if the number of loans is less than or equal to the number of copies.</p>
 <p>You can see this invariant at work, by selecting
 				<span class="bold"><strong>model/Tutorial.xmi</strong></span> and using the right button to invoke
 				<span class="bold"><strong>Open With-&gt;Sample Reflective Ecore Model Editor</strong></span>. This gives you a tree view of a small library model.
 			</p>
 <p>Expand the root element and then select the
 				<span class="bold"><strong>Library lib</strong></span> element and use the right button menu to invoke
 				<span class="bold"><strong>Validate</strong></span>. You should get a pop-up reporting problems during Validation. Click
 				<span class="bold"><strong>Details</strong></span> and you will see that one of the problems is with the
 				<span class="bold"><strong>SufficientCopies</strong></span> invariant we have just looked at. If you browse the Properties View for
 				<span class="bold"><strong>model/Tutorial.xmi</strong></span>, you can verify that there are three loans but only two copies for the offending Book.
 			</p>
 <p>You may evaluate custom OCL queries interactively. From the editor for
 				<span class="bold"><strong>Tutorial.xmi</strong></span>, invoke
 				<span class="bold"><strong>OCL-&gt;Show Xtext OCL Console</strong></span> from the context menu. Select
 				<span class="bold"><strong>Book b2</strong></span> in the editor, then in the bottom line of the console enter the OCL expression
 				<span class="bold"><strong>loans.member</strong></span> and then Enter. The results are shown in the panel and identify that all three loans are by
 				<span class="bold"><strong>Member m3</strong></span>.
 			</p>
 <p>The expression
 				<span class="bold"><strong>loans.member</strong></span> is an abbreviated form of
 				<span class="bold"><strong>self.loans-&gt;collect(aLoan : Loan | aLoan.member)</strong></span> and demonstrates OCL&rsquo;s ability to perform many useful navigations over multi-element properties. The expression
 			</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>navigates from self, the Book b2 selection</p>
 </li>
 <li class="listitem">
 <p>to its loans, using Book::loans which is a derived property defined in OCL</p>
 </li>
 <li class="listitem">
 <p>for each of the loans, the iterator variable, aLoan, is assigned to the loan and</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>the body, aLoan.member is evaluated to return the member making the loan</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>the resulting members are collected to return a collection result</p>
 </li>
 <li class="listitem">
 <p>the result is displayed on three lines in the results panel</p>
 </li>
 </ul>
 </div>
 <p>You can step through execution using the OCL debugger. In the Console View type PageUp to restore the earlier text entry, then with
 				<span class="bold"><strong>Book b2</strong></span> still selected in the editor, click the debug icon in the Console tool bar. The debugger should open automatically, but if it doesn&rsquo;t, use
 				<span class="bold"><strong>Window-&gt;Show View-&gt;Debug</strong></span> from the Eclipse menu bar. The Variables View shows model elemnt values. Click F5 or Step Into a few times to progress execution.
 			</p>
 <p>You have now seen</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>an Xtext editor that embeds OCL directly in Ecore models to provide programmed enrichment</p>
 </li>
 <li class="listitem">
 <p>execution of OCL while validating a model using conventional Ecore tooling</p>
 </li>
 <li class="listitem">
 <p>an interactive Console for custom OCL evaluations</p>
 </li>
 <li class="listitem">
 <p>execution of a derived property defined in OCL</p>
 </li>
 <li class="listitem">
 <p>the ability of OCL to express operations on multi-elements compactly</p>
 </li>
 <li class="listitem">
 <p>the ability to debug OCL execution and browse data</p>
 </li>
 </ul>
 </div>
 <p>You have not</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>written any Java code</p>
 </li>
 <li class="listitem">
 <p>generated any plugins</p>
 </li>
 <li class="listitem">
 <p>needed to start an additional Eclipse session</p>
 </li>
 </ul>
 </div>
 <p>Please follow the tutorials, examples and reference material for further information.</p>
 </div>
 </div>
 <div class="chapter" title="Chapter&nbsp;2.&nbsp;Users Guide">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title">
 <a name="UsersGuide"></a>Chapter&nbsp;2.&nbsp;Users Guide</h2>
 </div>
 </div>
 </div>
 <p>The core functionality of OCL that supports expressions over models is called the Essential OCL. This language is of very limited use by itself since there is no way in which the models can be provided.
 			Essential OCL is therefore extended in various ways to provide this missing context.</p>
 <p>The
 			<a class="link" href="#CompleteOCL" title="The Complete OCL Language">Complete OCL</a> provides a language for a document in which OCL complements an existing meta-model with invariants, and additional features.
 		</p>
 <p>

 <a class="link" href="#OCLinEcore" title="The OCLinEcore Language">OCLinEcore</a> embeds OCL within the annotations of an Ecore model to enrich that model.
 		</p>
 <p>UML supports the use of OCL constraints as a form of OpaqueExpression, and UML tools such as Papyrus support those constraints for UML models.</p>
 <p>The Eclipse OCL project provides four OCL languages to support these usages.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL" title="The Essential OCL Language">Essential OCL</a> provides the core extensible capability of specifying expressions for models.
 				</p>
 </li>
 </ul>
 </div>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#CompleteOCL" title="The Complete OCL Language">Complete OCL</a> provides the ability to use OCL in a self-standing document to complement an existing meta-model with invariants, and additional features.
 				</p>
 </li>
 </ul>
 </div>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#OCLinEcore" title="The OCLinEcore Language">OCLinEcore</a> enables OCL to be embedded within an Ecore meta-model to add invariants for classifiers, bodies for operations and computed values for properties.
 				</p>
 </li>
 </ul>
 </div>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#OCLstdlib" title="The OCL Standard Library Language">OCLstdlib</a> supports the definition of the standard and custom OCL Standard Libraries.
 				</p>
 </li>
 </ul>
 </div>
 <div class="section" title="The two Eclipse OCLs">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="EclipseOCLs"></a>The two Eclipse OCLs</h2>
 </div>
 </div>
 </div>
 <p>The Eclipse OCL project is making a transition to a new underlying infrastructure.</p>
 <div class="section" title="The Classic Eclipse OCL metamodels">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheClassicEclipseOCLmetamodels"></a>The Classic Eclipse OCL metamodels</h3>
 </div>
 </div>
 </div>
 <p>The Classic code base emphasized utility for Java programmers. It originally supported Ecore meta-models and evolved to support UML as well. An OCL Console was added to support interactive experimentation with OCL expressions.</p>
 <p>Interactions with the QVTd project resulted in a refactoring of the grammars so that they could be extended for use by QVT. At the same time the grammars were migrated to use LPG 2. </p>
 <p>The dual support for Ecore and UML was achieved by a shared generic meta-model in which the distinctions between Ecore and UML meta-models were accommodated by substantial (often ten parameter) template parameters lists. Sometimes these lists are hidden by derived bindings, but sometimes the full lists are exposed. This gives rather cumbersome Java code for the OCL developers and OCL consumers alike.</p>
 <p>The classic evaluator is tightly coupled to Ecore which might appear efficient, but the lack of separation of OCL-specification semantics from Java-implementation semantics makes accurate implementation of equality in nested collections hard to achieve.</p>
 <p>The classic code endeavored to comply with OCL specification despite significant ambiguities in the specification, but since the classic code evolved from an OCL 1.x compliance and Ecore utility there are a number of areas where accurate OMG compliance is hard to achieve.</p>
 <p>The classic code is provided primarily by the following plugins</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>org.eclipse.ocl</p>
 </li>
 <li class="listitem">
 <p>org.eclipse.ocl.ecore</p>
 </li>
 <li class="listitem">
 <p>org.eclipse.ocl.uml</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="The Unified or Pivot Eclipse OCL metamodel">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheUnifiedorPivotEclipseOCLmetamodel"></a>The Unified or Pivot Eclipse OCL metamodel</h3>
 </div>
 </div>
 </div>
 <p>The Unified or Pivot metamodel is a prototype for a resolution of a number of fundamental problems with the OCL 2.4 specification. The Pivot metamodel is derived from the UML metamodels for UML and OCL to provide a unified metamodel for UML with executable semantics.</p>
 <p>In practice, when using the Pivot metamodel for Ecore or UML metamodels, a Pivot metamodel instance is created on the fly to provide the unified merged OCL functionality for the Ecore or UML metamodel instances. </p>
 <p>From the specification perspective, the Pivot metamodel</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>is UML-aligned</p>
 </li>
 <li class="listitem">
 <p>supports modeling of the OCL standard library</p>
 </li>
 <li class="listitem">
 <p>supports &lsquo;merging&rsquo; of additional Complete OCL definitions</p>
 </li>
 <li class="listitem">
 <p>supports an interchangeable XMI representation</p>
 </li>
 <li class="listitem">
 <p>supports a fully reflective oclType()</p>
 </li>
 </ul>
 </div>
 <p>From the Eclipse perspective, the Pivot metamodel</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>hides Ecore differences with respect to EMOF</p>
 </li>
 <li class="listitem">
 <p>hides MDT/UML2 differences with respect to UML</p>
 </li>
 <li class="listitem">
 <p>allows much of the semantics to be defined by a single library model</p>
 </li>
 <li class="listitem">
 <p>allows user extension and replacement of the library model</p>
 </li>
 <li class="listitem">
 <p>allows for exact OMG compliance</p>
 </li>
 </ul>
 </div>
 <p>At the same time, the Values package that forms part of the specification has been partially implemented. This allows a clear separation of OCL-semantics.</p>
 <p>The unified code is provided by the</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>org.eclipse.ocl.pivot</p>
 </li>
 </ul>
 </div>
 <p>with additional optional support for UML in</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>org.eclipse.ocl.pivot.uml</p>
 </li>
 </ul>
 </div>
 <p>Additional editing functionality using Xtext is provided by plugins sharing the prefix </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>org.eclipse.ocl.xtext</p>
 </li>
 </ul>
 </div>
 <p>Further functionality that remains of exampe qulaity may be fopund in plugins sharing the prefix</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>org.eclipse.ocl.examples</p>
 </li>
 </ul>
 </div>
 <p>All APIs in Xtext and Examples plugins are preliminary, as are APIS in classes including &lsquo;internal&rsquo; in method, class or package name.</p>
 </div>
 <div class="section" title="The transition">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Thetransition"></a>The transition</h3>
 </div>
 </div>
 </div>
 <p>This transition started in the Helios (3.0) release for which Xtext editors were provided for OCLinEcore, Complete OCL and the OCL Standard Library. There was then no Pivot meta-model and so the editors offered only syntactic validation. It was not possible to persist an AST as XMI or to evaluate code that had been parsed by the Xtext parsers. It was necessary to re-parse with the LPG parsers. </p>
 <p>In the Indigo (3.1) release, the Pivot metamodel prototype was introduced and used to support semantic validation within the Xtext editors. The OCL Standard Library was realised using the Pivot metamodel and a new highly extensible evaluator was implemented. These facilities are used by the new OCL Xtext Console. </p>
 <p>Therefore when using the OCL Xtext Console the contributing tools are</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Essential OCL Xtext editor</p>
 </li>
 <li class="listitem">
 <p>Pivot Metamodel</p>
 </li>
 <li class="listitem">
 <p>OCL-2.5.oclstdlib library</p>
 </li>
 <li class="listitem">
 <p>Pivot Evaluator</p>
 </li>
 <li class="listitem">
 <p>Pivot Debugger</p>
 </li>
 </ul>
 </div>
 <p>When using the classic OCL Console the contributing tools are</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>LPG parser and hand-coded Syntax Helper</p>
 </li>
 <li class="listitem">
 <p>Ecore (or UML) metamodel bindings</p>
 </li>
 <li class="listitem">
 <p>Hand coded library implementation</p>
 </li>
 <li class="listitem">
 <p>Classic evaluator</p>
 </li>
 </ul>
 </div>
 <p>Since these tools are different there may be occasions where the increased OMG compliance of the Pivot metamodel gives different behavior to the classic metamodels.</p>
 <p>In the Juno (3.2/4.0) release, there is a preliminary Java code generator for the Pivot metamodel so that all the parsing overheads and significant parts of the execution overheads of OCL embedded in Ecore models occurs at genmodel time rather than during execution.</p>
 <p>In the Kepler (3.3/4.1) release, the code generator was substantially improved and a number of internal APIs have evolved accordingly. UML support was improved to facilitate usage within Papyrus, and extensibility was improved for use by QVTd.</p>
 <p>In the Luna (3.4/5.0) release, further code generation improvements have been made and major new User Interface capabilities added. There is at last an OCL debugger and a Constraint Validity View.</p>
 <p>In the Mars (1.0/6.0) release, the transition is nominally complete and the main org.eclipse.ocl.examples.* plugins have been renamed to org.eclipse.ocl.*. All functionality should use the new Pivot metamodel by default. However the classic Ecore and UML support will remain for compatibility. Unfortunately time ran out and so review and revision hads to be truncated. Documentation is sadly deficient.</p>
 <p>The Neon (1.1/6.1), Neon++(1.2/6.2), Oxygen (1.3/6.3) and Photon (1.4/6.4) resolve a variety of extensibility issues highlighted by Eclipse QVTd. (The double Neon release was necessiated by SSPI breakage in Xtext 2.9. The Neon release continuing with pre-Xtext 2.9 API, Neon++ migrating.)</p>
 <p>Hopefully the future (2.0/7.0) release will track the actual OCL 2.5 submission. </p>
 </div>
 <div class="section" title="Migration">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Migration"></a>Migration</h3>
 </div>
 </div>
 </div>
 <p>The difficulties of moving from the Ecore/UML-based OCL to the Pivot-based OCL depend on the style of usage.</p>
 <div class="section" title="Language">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Language"></a>Language</h4>
 </div>
 </div>
 </div>
 <p>The OCL Concrete Syntax is the same for both Eclipse OCLs and Pivot-based Xtext tooling has been in use for Ecore-based OCL for a few releases.</p>
 <p>The Pivot-based OCL supports a number of new prototype facilities such as null-free collections, template types, map types and lambda types that are not available with the Ecore-based tooling.</p>
 </div>
 <div class="section" title="AS Models">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ASModels"></a>AS Models</h4>
 </div>
 </div>
 </div>
 <p>The Abstract Syntax models are superficially similar; both have an OCLExpression, however the details are quite different.</p>
 <p>The OMG OCL specification requires the AS model to be serializeable in XMI. This is not possible with the current OCL specifications. The intent is partially satisfied for the Ecore/UML-based models using proprietary solutions. The Pivot-based models are fully serializeable and prototype a solution that may be adopted by OCL 2.5.</p>
 <p>The Ecore/UML-based models extend the Ecore.ecore/UML.ecore models and so use for instance EStructuralFeature/org.eclipse.uml2.uml.Property as the type of a PropertyCallExp.referredProperty.</p>
 <p>The Pivot-based models are UML-aligned and self-contained and so a PropertyCallExp.referredProperty is an org.eclipse.ocl.pivot.Property. Property names are derived from UML but made consistent; &lsquo;many&rsquo; properties use a plural name; and 'composed; properties use &lsquo;owned&rsquo;/&lsquo;owning&rsquo;. Thus UML&rsquo;s Class.ownedAttribute aligns to Pivot&rsquo;s Class.ownedProperties.</p>
 <p>Since the Pivot-based models have no dependence on an external model, the Pivot Visitors provide an ability to visit all classes, whereas the Ecore/UML-based visitors are partial; Ecore/UML classes must use an EcoreSwitch instead.</p>
 <p>The Ecore/UML based models have no support for UML reflection. A form of reflection is available with eClass(), but the result type names are necessarily EClass.</p>
 <p>The Pivot-based models support consistent reflection using oclType() which return an ocl.eclipse.ocl.pivot.Class.</p>
 <p>The Ecore/UML-based OCL does not use models for additional facilities defined by Complete OCL; an irregular Java API is available.</p>
 <p>The Pivot-based approach creates an additional Package for the Complete OCL contributions and behaves as if the complementing Package was merged with the complemented Package.</p>
 </div>
 <div class="section" title="CS Models">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CSModels"></a>CS Models</h4>
 </div>
 </div>
 </div>
 <p>The Concrete Syntax models are non-normative and have very little commonality.</p>
 <p>The Ecore/UML-based models are designed for use with the LPG LALR parser.</p>
 <p>The Pivot-based models are designed for use with Xtext and LL ANTLR tooling.</p>
 <p>Any user code that uses the CS models is likely to be very tightly coupled to internal APIs and so will need rebuilding and quite possibly updating for each new release.</p>
 </div>
 <div class="section" title="The OCL Facade">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="TheOCLFacade"></a>The OCL Facade</h4>
 </div>
 </div>
 </div>
 <p>The complexities of the underlying OCL support are hidden by an OCL Facade, with similar interfaces in all three variants.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>org.eclipse.ocl.ecore.OCL </p>
 </li>
 <li class="listitem">
 <p>org.eclipse.ocl.uml.OCL </p>
 </li>
 <li class="listitem">
 <p>org.eclipse.ocl.pivot.utilities.OCL</p>
 </li>
 </ul>
 </div>
 <p>Contrasting the deliberately similar examples in</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#ProgrammersGuide" title="Chapter&nbsp;6.&nbsp;Classic Ecore/UML Programmers Guide">Classic Ecore/UML Programmers Guide</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#PivotProgrammersGuide" title="Chapter&nbsp;7.&nbsp;Unified or Pivot Programmers Guide">Unified or Pivot Programmers Guide</a>

 </p>
 </li>
 </ul>
 </div>
 <p>may be instructive.</p>
 <p>The Pivot approach is simplified a little by the dual Facade/Handle behavior which ensures that OCL facilities are garbage collected.</p>
 </div>
 <div class="section" title="The OCL Architecture">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="TheOCLArchitecture"></a>The OCL Architecture</h4>
 </div>
 </div>
 </div>
 <p>While many of the internal classes share similar intents and names between the approaches, the details have evolved as the new approach has learned from its predecessor</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>long template parameter lists are eliminated</p>
 </li>
 <li class="listitem">
 <p>APIs are more strongly typed using e.g. TypedElement rather than String &lsquo;name&rsquo; arguments</p>
 </li>
 <li class="listitem">
 <p>API compatible extension APIs are folded into a single new API</p>
 </li>
 <li class="listitem">
 <p>full auto-generated Visitor hierarchies are exploited</p>
 </li>
 </ul>
 </div>
 <p>and of course Xtext is far from identical to LPG.</p>
 </div>
 </div>
 <div class="section" title="APIs">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="APIs"></a>APIs</h3>
 </div>
 </div>
 </div>
 <p>Eclipse OCL has two different styles of APIs</p>
 <div class="section" title="Tool APIs">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ToolAPIs"></a>Tool APIs</h4>
 </div>
 </div>
 </div>
 <p>The major tool APIs originally provided by the org.eclipse.ocl.OCL class have evolved only slightly to org.eclipse.ocl.ecore.OCL and org.eclipse.ocl.uml.OCL for the classic metamodels and org.eclipse.ocl.pivot.OCL for the Pivot metamodel.</p>
 <p>These APIs support the use of OCL as a tool to parse and evaluate constraints and queries.</p>
 <p>These APIs will change very little; just the package changes according to the chosen metamodel representation.</p>
 </div>
 <div class="section" title="Internal APIs">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="InternalAPIs"></a>Internal APIs</h4>
 </div>
 </div>
 </div>
 <p>The internal parsing APIs were made public in 1.3.0 to support parser extension by QVT. These APIs are very tightly coupled to a particular LPG implementation of a particular OCL grammar formulation. It is extremely difficult to replicate these APIs for the ANTLR grammar that underlies the Xtext editors. It is also doubtful whether these APIs can be preserved as the OCL specification is clarified to more clearly specify what words are reserved and what is extensible. </p>
 <p>It is therefore unlikely that the internal APIs for the classic metamodels will be replicated for the Pivot metamodel. However since an LPG grammar is significantly (ten-times) smaller and perhaps a bit faster (two-times) it is planned to provide an automated Xtext to LPG translation so that a smaller LPG grammar can populate the same auto-generated Concrete Syntax structures as the ANTLR grammar.</p>
 <p>This functionality is intended to form part of a new grammar extension API that will enable OCL-extending languages such as QVT to re-use and extend not only the grammar but also all the semantic scope resolution and concrete to abstract syntax mappings.</p>
 </div>
 <div class="section" title="Versions">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Versions"></a>Versions</h4>
 </div>
 </div>
 </div>
 <p>Eclipse version numbering policy requires that a major version change occurs when any re-exported component has a major version number change. Consequently when Eclipse UML moved from to UML 2.4 support (4.0.0) and again to UML 2.5 (5.0.0) a corresponding change was forced on the Classic UML support and this is the number that then applies to the whole of Eclipse OCL. However the Ecore dependencies are unchanged and so Ecore dependent releases have advanced more slowly; 3.2 accompanying 4.0 and now 3.5 accompanying 6.0.</p>
 <p>This is probably just as confusing for the developers as for consumers. It is however necessary to ensure that the minor changes in the Classic Ecore functionality are not presented as major changes to consumers.</p>
 <p>The current OCL version variaously referred to as:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>6.0 as the outer version of the OCL master feature</p>
 </li>
 <li class="listitem">
 <p>3.5 as the version of the Ecore OCL plugins (compatible with 3.0)</p>
 </li>
 <li class="listitem">
 <p>1.0 as the version of the new Pivot OCL plugins</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 </div>
 <div class="section" title="The Essential OCL Language">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="EssentialOCL"></a>The Essential OCL Language</h2>
 </div>
 </div>
 </div>
 <p>The core functionality of OCL that supports expressions over models is called the Essential OCL. This language is of very limited use by itself since there is no way in which the models can be provided.</p>
 <p>Essential OCL is extended in various ways to provide this missing context.</p>
 <p>The
 				<a class="link" href="#CompleteOCL" title="The Complete OCL Language">Complete OCL</a> provides a language for a document in which OCL complements an existing meta-model with invariants, and additional features. Complete OCL is part of the OMG OCL specification.
 			</p>
 <p>

 <a class="link" href="#OCLinEcore" title="The OCLinEcore Language">OCLinEcore</a> embeds OCL within the annotations of an Ecore model to enrich that model. OCLinEcore is defined an Eclipse OCL. It is not part of the OMG OCL specification.
 			</p>
 <p>UML supports the use of OCL constraints as a form of OpaqueExpression, and UML tools such as Papyrus support those constraints for UML models.</p>
 <div class="section" title="Syntax">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Syntax"></a>Syntax</h3>
 </div>
 </div>
 </div>
 <p>The Eclipse OCL realization of the Essential OCL grammar is provided in the following subsections, starting with the expression terms and then elaborating the operators.</p>
 <div class="section" title="Grammar Implementation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="GrammarImplementation"></a>Grammar Implementation</h4>
 </div>
 </div>
 </div>
 <p>The grammar used by the Xtext editors may be found at:</p>
 <p>/src/org/eclipse/ocl/examples/xtext/essentialocl/EssentialOCL.xtext</p>
 <p>in the org.eclipse.ocl.xtext.essentialocl plugin.</p>
 </div>
 <div class="section" title="Grammar Approach">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="GrammarApproach"></a>Grammar Approach</h4>
 </div>
 </div>
 </div>
 <p>The OCL 2.4 grammar is ambiguous and consequently has disambigating rules. How those disambiguating rules are applied is an implementation detail.</p>
 <p>The disambiguating approach taken in Eclipse OCL is to parse an unambiguous larger language that unifies all the ambiguities. Subsequent semantic validation distinguishes between the ambiguities and diagnoses expressions from the larger language that are not valid OCL expressions.</p>
 <p>From a technical point of view this makes the grammar simpler and more regular, and the implementation more modular and configurable by the library model.</p>
 <p>From a user&rsquo;s point of view, slightly wrong expressions may be syntactically valid and so semantic validation may produce a more helpful diagnostic. However completion assist may offer illegal expressions from the larger language.</p>
 </div>
 <div class="section" title="OCL Expression">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-Exp"></a>OCL Expression</h4>
 </div>
 </div>
 </div>
 <p>The Exp syntax defines an OCL expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-exp.png"></div>
 <p>

 </p>
 <p>Expressions consist of a variety of operators and expression terms that are defined at the top level by an
 						<a class="link" href="#EssentialOCL-InfixedExp" title="InfixedExp">InfixedExp</a>. We will first define the terms of an expression and then define the various forms of operators that bind expression terms together.
 					</p>
 </div>
 <div class="section" title="PrimaryExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-PrimaryExp"></a>PrimaryExp</h4>
 </div>
 </div>
 </div>
 <p>The PrimaryExp syntax identifies the basic building blocks of an OCL expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-primaryexp.png"></div>
 <p>

 </p>
 <p>Literals such as</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-PrimitiveLiteralExp" title="PrimitiveLiteralExp">PrimitiveLiteralExpCS</a> -
 								<code class="code">true</code> or
 								<code class="code">3.14159</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-CollectionLiteralExp" title="CollectionLiteralExp">CollectionLiteralExpCS</a> -
 								<code class="code">Set{1..5}</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-TupleLiteralExp" title="TupleLiteralExp">TupleLiteralExpCS</a> -
 								<code class="code">Tuple{name:String='me',at:String='here')</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-TypeLiteralExp" title="TypeLiteralExp">TypeLiteralExpCS</a> -
 								<code class="code">Integer</code> or
 								<code class="code">Set&lt;Integer&gt;</code>

 </p>
 </li>
 </ul>
 </div>
 <p>The context object</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-SelfExp" title="SelfExp">SelfExpCS</a> -
 								<code class="code">self</code>

 </p>
 </li>
 </ul>
 </div>
 <p>Compound expressions such as</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-NestedExp" title="NestedExp">NestedExpCS</a> -
 								<code class="code">(x)</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-IfExp" title="IfExp">IfExpCS</a> -
 								<code class="code">if x then y else z endif</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-LetExp" title="LetExp">LetExpCS</a> -
 								<code class="code">let x : Integer in x + x</code>

 </p>
 </li>
 </ul>
 </div>
 <p>Navigation expressions such as</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-NavigatingExp" title="NavigatingExp">NavigatingExpCS</a> -
 								<code class="code">x</code> or
 								<code class="code">x.Y::z-&gt;iterate(a:Integer;acc:Integer|acc+a)</code>

 </p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="SelfExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-SelfExp"></a>SelfExp</h4>
 </div>
 </div>
 </div>
 <p>The SelfExp syntax supports the use of the prevailing context object in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-selfexp.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="PrimitiveLiteralExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-PrimitiveLiteralExp"></a>PrimitiveLiteralExp</h4>
 </div>
 </div>
 </div>
 <p>The PrimitiveLiteralExp syntax supports the use of a known value in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-primitiveliteralexp.png"></div>
 <p>

 </p>
 <p>The value may be </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-NumberLiteralExp" title="NumberLiteralExp">NumberLiteralExpCS</a> -
 								<code class="code">4</code> or
 								<code class="code">3.14159</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-StringLiteralExp" title="StringLiteralExp">StringLiteralExpCS</a> -
 								<code class="code">'a string'</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-BooleanLiteralExp" title="BooleanLiteralExp">BooleanLiteralExpCS</a> -
 								<code class="code">true</code> or
 								<code class="code">false</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-UnlimitedNaturalLiteralExp" title="UnlimitedNaturalLiteralExp">UnlimitedNaturalLiteralExpCS</a> -
 								<code class="code">*</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-InvalidLiteralExp" title="InvalidLiteralExp">InvalidLiteralExpCS</a> -
 								<code class="code">invalid</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-NullLiteralExp" title="NullLiteralExp">NullLiteralExpCS</a> -
 								<code class="code">null</code>

 </p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="NumberLiteralExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-NumberLiteralExp"></a>NumberLiteralExp</h4>
 </div>
 </div>
 </div>
 <p>The NumberLiteralExp syntax supports the use of a numeric value in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-numberliteralexp.png"></div>
 <p>

 </p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-numberliteral.png"></div>
 <p>

 </p>
 <p>A numeric value is</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>an integer such as
 								<code class="code">4</code>

 </p>
 </li>
 <li class="listitem">
 <p>fixed point number such as
 								<code class="code">3.1</code>

 </p>
 </li>
 <li class="listitem">
 <p>floating point number such as
 								<code class="code">12.8e-5</code>.
 							</p>
 </li>
 </ul>
 </div>
 <p>A numeric value does not have a leading
 						<code class="code">-</code>; negative numbers are parsed as the application of a unary negate operator to a positive number.
 					</p>
 <p>A numeric value may not have a trailing decimal point.</p>
 <p>A numeric value may not have a redundant leading zero.</p>
 </div>
 <div class="section" title="StringLiteralExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-StringLiteralExp"></a>StringLiteralExp</h4>
 </div>
 </div>
 </div>
 <p>The StringLiteralExp syntax supports the use of a string value in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-stringliteralexp.png"></div>
 <p>

 </p>
 <p>A string is specified as a character sequence between single quotes.</p>
 <p>e.g.
 						<code class="code">'This is a string'</code>

 </p>
 <p>The standard Java and C backslash escapes can be used for awkward characters such as a single quote.</p>
 <p>

 <code class="code">\b</code> -- #x08: backspace BS
 					</p>
 <p>

 <code class="code">\t</code> -- #x09: horizontal tab HT
 					</p>
 <p>

 <code class="code">\n</code> -- #x0a: linefeed LF
 					</p>
 <p>

 <code class="code">\f</code> -- #x0c: form feed FF
 					</p>
 <p>

 <code class="code">\r</code> -- #x0d: carriage return CR
 					</p>
 <p>

 <code class="code">\"</code> -- #x22: double quote "
 					</p>
 <p>

 <code class="code">\'</code> -- #x27: single quote '
 					</p>
 <p>

 <code class="code">\\</code> -- #x5c: backslash \
 					</p>
 <p>

 <code class="code">\x</code> Hex Hex -- #x00 to #xFF
 					</p>
 <p>

 <code class="code">\u</code> Hex Hex Hex Hex -- #x0000 to #xFFFF
 					</p>
 </div>
 <div class="section" title="BooleanLiteralExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-BooleanLiteralExp"></a>BooleanLiteralExp</h4>
 </div>
 </div>
 </div>
 <p>The BooleanLiteralExp syntax supports the use of boolean values in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-booleanliteralexp.png"></div>
 <p>

 </p>
 <p>The Boolean values are
 						<code class="code">true</code> and
 						<code class="code">false</code>.
 					</p>
 </div>
 <div class="section" title="UnlimitedNaturalLiteralExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-UnlimitedNaturalLiteralExp"></a>UnlimitedNaturalLiteralExp</h4>
 </div>
 </div>
 </div>
 <p>The UnlimitedNaturalLiteralExp syntax supports the use of the non-numeric unlimited value in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-unlimitednaturalliteralexp.png"></div>
 <p>

 </p>
 <p>The Non-numeric unlimited value is
 						<code class="code">*</code>. Other UnlimitedNatural values are
 						<a class="link" href="#EssentialOCL-NumberLiteralExp" title="NumberLiteralExp">NumberLiteralExpCS</a>.
 					</p>
 </div>
 <div class="section" title="InvalidLiteralExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-InvalidLiteralExp"></a>InvalidLiteralExp</h4>
 </div>
 </div>
 </div>
 <p>The InvalidLiteralExp syntax supports the use of an invalid value in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-invalidliteralexp.png"></div>
 <p>

 </p>
 <p>The invalid value is
 						<code class="code">invalid</code>.
 					</p>
 </div>
 <div class="section" title="NullLiteralExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-NullLiteralExp"></a>NullLiteralExp</h4>
 </div>
 </div>
 </div>
 <p>The NullLiteralExp syntax supports the use of a null or unspecified value in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-nullliteralexp.png"></div>
 <p>

 </p>
 <p>The null value is
 						<code class="code">null</code>.
 					</p>
 </div>
 <div class="section" title="CollectionLiteralExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-CollectionLiteralExp"></a>CollectionLiteralExp</h4>
 </div>
 </div>
 </div>
 <p>The CollectionLiteralExp syntax supports the creation of a collection of values for use in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-collectionliteralexp.png"></div>
 <p>

 </p>
 <p>A collection literal comprises the
 						<a class="link" href="#EssentialOCL-CollectionType" title="CollectionType">CollectionType</a> followed by braces enclosing a comma-separated list of zero or more
 						<a class="link" href="#EssentialOCL-CollectionLiteralPart" title="CollectionLiteralPart">CollectionLiteralParts</a>.
 					</p>
 <p>e.g.
 						<code class="code">Sequence{1,2,4..6}</code>

 </p>
 <p>Note that null, collection and tuple values are permitted in collections but that invalid values are not.
 						A collection &lsquo;containing&rsquo; an invalid value is flattened to the invalid value.</p>
 </div>
 <div class="section" title="CollectionLiteralPart">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-CollectionLiteralPart"></a>CollectionLiteralPart</h4>
 </div>
 </div>
 </div>
 <p>The CollectionLiteralPart syntax supports the use of a value or range of values in a collection of values.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-collectionliteralpart.png"></div>
 <p>

 </p>
 <p>A single item collection literal part may be any expression (except invalid). e.g.
 						<code class="code">1+2</code>

 </p>
 <p>A multi-item collection literal part comprises the inclusive range of values between two integer limits.</p>
 <p>

 <code class="code">1..3</code> is the three values
 						<code class="code">1</code>,
 						<code class="code">2</code>,
 						<code class="code">3</code>.
 					</p>
 <p>

 <code class="code">1..-1</code> is the three values
 						<code class="code">1</code>,
 						<code class="code">0</code>,
 						<code class="code">-1</code>.
 					</p>
 </div>
 <div class="section" title="TupleLiteralExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-TupleLiteralExp"></a>TupleLiteralExp</h4>
 </div>
 </div>
 </div>
 <p>The TupleLiteralExp syntax supports the use of a tuple of named expression values in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-tupleliteralexp.png"></div>
 <p>

 </p>
 <p>A tuple literal comprises the
 						<code class="code">Tuple</code> keyword followed by braces enclosing
 						a comma-separated list of one or more
 						<a class="link" href="#EssentialOCL-TupleLiteralPart" title="TupleLiteralPart">TupleLiteralParts</a>.
 					</p>
 <p>

 <code class="code">Tuple{year:Integer='2000',month:String='January',day:Integer='1'}</code>

 </p>
 </div>
 <div class="section" title="TupleLiteralPart">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-TupleLiteralPart"></a>TupleLiteralPart</h4>
 </div>
 </div>
 </div>
 <p>The TupleLiteralPart syntax supports the use of a named expression value in a tuple of such values.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-tupleliteralpart.png"></div>
 <p>

 </p>
 <p>The part comprises the name, an optional type and a value. If the type is omitted, it is inferred from the value.</p>
 <p>

 <code class="code">leapyear : Boolean = true</code>

 </p>
 </div>
 <div class="section" title="TypeLiteralExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-TypeLiteralExp"></a>TypeLiteralExp</h4>
 </div>
 </div>
 </div>
 <p>The TypeLiteralExp syntax supports the use of types as values in an expression. This is useful for expressions such as
 						<code class="code">myCollection.oclAsType(Set&lt;MyType&gt;)</code>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-typeliteralexp.png"></div>
 <p>

 </p>
 <p>A TypeLiteralExp comprises a
 						<a class="link" href="#EssentialOCL-TypeLiteral" title="TypeLiteral">TypeLiteral</a>.
 					</p>
 </div>
 <div class="section" title="NestedExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-NestedExp"></a>NestedExp</h4>
 </div>
 </div>
 </div>
 <p>The NestedExp syntax supports the use of an inner expression as a term in an outer expression ensuring that
 						the operator precedence of the inner expression is not affected by the outer expression,</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-nestedexp.png"></div>
 <p>

 </p>
 <p>A nested expression is just an expression surrounded by parentheses.</p>
 </div>
 <div class="section" title="IfExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-IfExp"></a>IfExp</h4>
 </div>
 </div>
 </div>
 <p>The IfExp syntax supports the use of a conditional choice of expression value in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-ifexp.png"></div>
 <p>

 </p>
 <p>An if expression comprises a condition expression to be tested followed by a then-expression
 						to be evaluated if the condition is true and an else-expression for evaluation if the expression is false.</p>
 <p>

 <code class="code">if this.size &gt; that.size then this else that endif</code>

 </p>
 <p>Note that the else-expression is required and so there is no ambiguity when multiple if expressions are nested.</p>
 </div>
 <div class="section" title="LetExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-LetExp"></a>LetExp</h4>
 </div>
 </div>
 </div>
 <p>The LetExp syntax supports the introduction of local variables to facilitate re-use of intermediate results within an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-letexp.png"></div>
 <p>

 </p>
 <p>A let expression comprises the let keyword followed by one or more comma-separated let variables and then the in keyword and
 						the in-expression to be evaluated with the help of the extra variables.</p>
 <p>Each let variable comprises a name, an optional type and an expression to initialize the variable. If the type is omitted, it is inferred from the initializer.</p>
 <div class="literallayout">
 <p>
 <code class="code">let&nbsp;test&nbsp;:&nbsp;String&nbsp;=&nbsp;'prefix[contents]suffix',<br>
 &nbsp;&nbsp;&nbsp;&nbsp;start&nbsp;:&nbsp;Integer&nbsp;=&nbsp;test.indexOf('['),<br>
 &nbsp;&nbsp;&nbsp;&nbsp;finish&nbsp;:&nbsp;Integer&nbsp;=&nbsp;test.indexOf(']')<br>
 in&nbsp;test.substring(start,finish)<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The let syntax has no terminating keyword such as endlet and so there is an ambiguity for for instance
 						<code class="code">1 + let b : Integer = 2 in b + 4</code>. The ambiguity is resolved as
 						<code class="code">1 + let b : Integer = 2 in (b + 4)</code> by selecting the longest possible in-expression.
 					</p>
 </div>
 <div class="section" title="NameExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-NameExp"></a>NameExp</h4>
 </div>
 </div>
 </div>
 <p>The NameExp syntax supports the use of the name of a model  element such as a property, operation or type in an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-nameexp.png"></div>
 <p>

 </p>
 <p>A name expression comprises a name optionally prefixed by double-colon separate path names.</p>
 <p>The first name is an
 						<a class="link" href="#EssentialOCL-UnrestrictedName" title="UnrestrictedName">UnrestrictedName</a>, that is a name that does not clash with any OCL reserved words such as
 						<code class="code">else</code> or built-in types such as
 						<code class="code">String</code>. Subsequent names are
 						<a class="link" href="#EssentialOCL-UnreservedName" title="UnreservedName">UnreservedName</a> allowing the re-use of built-in type names but not reserved words.
 					</p>
 </div>
 <div class="section" title="IndexExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-IndexExp"></a>IndexExp</h4>
 </div>
 </div>
 </div>
 <p>The IndexExp syntax supports the application of qualifiers to a model property to distinguish the source or select a particular association.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-indexexp1.png"></div>
 <p>

 </p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-indexexp2.png"></div>
 <p>

 </p>
 <p>A
 						<a class="link" href="#EssentialOCL-NameExp" title="NameExp">NameExp</a> identifying a model property is optionally qualified by a first list of qualifiers and a second list of qualifiers.
 					</p>
 <p>This syntax is experimental and the qualifiers are not yet supported for evaluation.</p>
 </div>
 <div class="section" title="NavigatingExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-NavigatingExp"></a>NavigatingExp</h4>
 </div>
 </div>
 </div>
 <p>The NavigatingExp syntax supports the navigation of models using model properties, operations and iterations.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-navigatingexp1.png"></div>
 <p>

 </p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-navigatingexp2.png"></div>
 <p>

 </p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-navigatingexp3.png"></div>
 <p>

 </p>
 <p>An
 						<a class="link" href="#EssentialOCL-IndexExp" title="IndexExp">IndexExp</a> identifying a potentially qualified model feature is optionally followed by a parenthesized arguments. If the parenthesized arguments are omitted the model feature should be a Property. If the arguments are present the model feature should be an iteration or operation.
 					</p>
 <p>The diverse syntaxes specified by OCL 2.4 for OperationCallExpCS and IteratorExpCS create ambiguities that are difficult to parse. The merged grammar used by Eclipse OCL gathers argument
 						contributions without imposing premature validation.</p>
 <p>The parenthesized arguments may be empty, or may comprise one or more parameters, optional accumulators and optional bodies.</p>
 <p>The comma-separated list of parameters starts with a NavigatingArgCS, followed by any number of
 						NavigatingCommaArgCS.</p>
 <p>

 <code class="code">simpleCall(simpleArgument)</code>

 </p>
 <p>The optional comma-separated list of accumulators are introduced by a semi-colon-prefixed NavigatingSemiArgCS, followed by any number of  NavigatingCommaArgCS. </p>
 <p>

 <code class="code">some-&gt;iterate(p; anAccumulator : Integer = 0 | p.size())</code>

 </p>
 <p>The optional comma-separated list of bodies are introduced by a vertical-bar-prefixed NavigatingBarArgCS, followed by any number of  NavigatingCommaArgCS. </p>
 <p>

 <code class="code">some-&gt;exists(p | p.size())</code>

 </p>
 </div>
 <div class="section" title="NavigatingArg">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-NavigatingArg"></a>NavigatingArg</h4>
 </div>
 </div>
 </div>
 <p>The NavigatingArg syntaxes supports the parsing of potential parameters, accumulators and bodies for use in NavigatingExps.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-navigatingarg.png"></div>
 <p>

 </p>
 <p>Each syntax supports an optional type and an optional initializer for an expression.</p>
 </div>
 <div class="section" title="PrefixedExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-PrefixedExp"></a>PrefixedExp</h4>
 </div>
 </div>
 </div>
 <p>The PrefixedExp syntax supports the application of zero or more prefix unary operators to an expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-prefixedexp.png"></div>
 <p>

 </p>
 <p>The prefix operator precedes an expression:
 						<code class="code">-4</code> or
 						<code class="code">not(this or that)</code>

 </p>
 <p>The unary operators are</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">-</code> negate
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">not</code> logical complement
 							</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="InfixedExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-InfixedExp"></a>InfixedExp</h4>
 </div>
 </div>
 </div>
 <p>The InfixedExp syntax supports the application of zero or more infix binary operators between expression terms.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-infixedexp.png"></div>
 <p>

 </p>
 <p>The infix operators separate expression terms:
 						<code class="code">1 + 2 / 3 * 4 / 5 + 6</code>.
 					</p>
 <p>The infix operators are</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>The
 								<a class="link" href="#EssentialOCL-NavigationOperators" title="NavigationOperators">NavigationOperators</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">*</code>,
 								<code class="code">/</code> multiply and divide
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">+</code>,
 								<code class="code">-</code> add and subtract
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">&lt;</code>,
 								<code class="code">&lt;=</code>,
 								<code class="code">&gt;=</code>,
 								<code class="code">&gt;</code> relational comparisons
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">=</code>,
 								<code class="code">&lt;&gt;</code> equality and inequality
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">and</code> logical and
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">or</code> inclusive or
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">xor</code> exclusive or
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">implies</code> logical implication
 							</p>
 </li>
 </ul>
 </div>
 <p>The precedence and associativity of the operators is defined by the OCL Standard Library model, not by the grammar. The OCL 2.4 library precedence is as presented above with all operators left associative. The example above is therefore interpreted as
 						<code class="code">(1 + (((2 / 3) * 4) / 5)) + 6</code>.
 					</p>
 </div>
 <div class="section" title="NavigationOperators">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-NavigationOperators"></a>NavigationOperators</h4>
 </div>
 </div>
 </div>
 <p>The NavigationOperators operators are</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">.</code> for object navigation
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">-&gt;</code> for collection navigation
 							</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="TypeExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-TypeExp"></a>TypeExp</h4>
 </div>
 </div>
 </div>
 <p>The TypeExp syntax supports the use of types as expressions.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-typeexp.png"></div>
 <p>

 </p>
 <p>A type expression may be a</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-TypeNameExp" title="TypeNameExp">TypeNameExpCS</a> - a user-defined type
 							</p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-TypeLiteral" title="TypeLiteral">TypeLiteralCS</a> - a built-in or aggregate type
 							</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="TypeNameExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-TypeNameExp"></a>TypeNameExp</h4>
 </div>
 </div>
 </div>
 <p>The TypeNameExp syntax supports the use of a user-defined types as a declaration or expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-typenameexp.png"></div>
 <p>

 </p>
 <p>A name expression comprises the name of a type optionally prefixed by double-colon separate path names.</p>
 <p>The first name is an
 						<a class="link" href="#EssentialOCL-UnrestrictedName" title="UnrestrictedName">UnrestrictedName</a>, that is a name that does not clash with any OCL reserved words such as
 						<code class="code">else</code> or built-in types such as
 						<code class="code">String</code>. Subsequent names are
 						<a class="link" href="#EssentialOCL-UnreservedName" title="UnreservedName">UnreservedName</a> allowing the re-use of built-in type names but not reserved words.
 					</p>
 </div>
 <div class="section" title="TypeLiteral">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-TypeLiteral"></a>TypeLiteral</h4>
 </div>
 </div>
 </div>
 <p>The TypeLiteral syntax supports the use of built-in or aggregate types as declarations or expressions.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-typeliteral.png"></div>
 <p>

 </p>
 <p>A Type literal may be a</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-PrimitiveType" title="PrimitiveType">PrimitiveTypeCS</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-CollectionType" title="CollectionType">CollectionTypeCS</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EssentialOCL-TupleType" title="TupleType">TupleTypeCS</a>

 </p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="PrimitiveType">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-PrimitiveType"></a>PrimitiveType</h4>
 </div>
 </div>
 </div>
 <p>The PrimitiveType syntax supports the definition of a built-in type for use in a declaration or expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-primitivetype.png"></div>
 <p>

 </p>
 <p>The built-in types are</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Boolean</p>
 </li>
 <li class="listitem">
 <p>Integer</p>
 </li>
 <li class="listitem">
 <p>Real</p>
 </li>
 <li class="listitem">
 <p>String</p>
 </li>
 <li class="listitem">
 <p>UnlimitedNatural</p>
 </li>
 <li class="listitem">
 <p>OclAny</p>
 </li>
 <li class="listitem">
 <p>OclInvalid</p>
 </li>
 <li class="listitem">
 <p>OclVoid</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="CollectionType">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-CollectionType"></a>CollectionType</h4>
 </div>
 </div>
 </div>
 <p>The CollectionType syntax supports the definition of a collection type for use in a declaration or expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-collectiontype.png"></div>
 <p>

 </p>
 <p>A collection type comprises the CollectionTypeIdentifier followed by a
 						<a class="link" href="#EssentialOCL-TypeExp" title="TypeExp">Type Expression</a> defining the type of the collection elements.
 					</p>
 <p>

 <code class="code">Set(String)</code> or
 						<code class="code">Sequence&lt;Bag&lt;Integer&gt;&gt;</code>

 </p>
 <p>The built-in CollectionTypeIdentifiers are</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Collection</p>
 </li>
 <li class="listitem">
 <p>Bag</p>
 </li>
 <li class="listitem">
 <p>OrderedSet</p>
 </li>
 <li class="listitem">
 <p>Sequence</p>
 </li>
 <li class="listitem">
 <p>Set</p>
 </li>
 </ul>
 </div>
 <p>OCL 2.4 specifies the use of parentheses to surround the element type. Eclipse OCL additionally allows angle brackets as specified by UML and as may be required to support more general templated types.</p>
 </div>
 <div class="section" title="TupleType">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-TupleType"></a>TupleType</h4>
 </div>
 </div>
 </div>
 <p>The TupleType syntax supports the definition of a tuple type for use in a declaration or expression.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-tupletype.png"></div>
 <p>

 </p>
 <p>A tuple type comprises the
 						<code class="code">Tuple</code> keyword followed by
 						a comma-separated list of one or more
 						<a class="link" href="#EssentialOCL-TuplePart" title="TuplePart">TupleParts</a>.
 					</p>
 <p>OCL 2.4 specifies the use of parentheses to surround the parts. Eclipse OCL additionally allows angle brackets as specified by UML and as may be required to support more general templated types.</p>
 <p>

 <code class="code">Tuple&lt;year:Integer,month:String,day:Integer&gt;</code>

 </p>
 </div>
 <div class="section" title="TuplePart">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-TuplePart"></a>TuplePart</h4>
 </div>
 </div>
 </div>
 <p>The TuplePart syntax supports the definition of an element of a TupleType.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1100-tuplepart.png"></div>
 <p>

 </p>
 <p>The part comprises the name and a type and a value. </p>
 <p>

 <code class="code">leapyear : Boolean</code>

 </p>
 </div>
 <div class="section" title="UnreservedName">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-UnreservedName"></a>UnreservedName</h4>
 </div>
 </div>
 </div>
 <p>The Essential OCL reserved words are
 						<code class="code">and</code>,
 						<code class="code">else</code>,
 						<code class="code">endif</code>,
 						<code class="code">false</code>,
 						<code class="code">if</code>,
 						<code class="code">implies</code>,
 						<code class="code">in</code>,
 						<code class="code">invalid</code>,
 						<code class="code">let</code>,
 						<code class="code">not</code>,
 						<code class="code">null</code>,
 						<code class="code">or</code>,
 						<code class="code">self</code>,
 						<code class="code">then</code>,
 						<code class="code">true</code>,
 						<code class="code">xor</code>. These
 						can only be used as names when escaped as in
 						<code class="code">_'self'</code>.
 					</p>
 </div>
 <div class="section" title="UnrestrictedName">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EssentialOCL-UnrestrictedName"></a>UnrestrictedName</h4>
 </div>
 </div>
 </div>
 <p>The Essential OCL restricted words are the reserved words above and the OCL reserved type names which are
 						<code class="code">Bag</code>,
 						<code class="code">Boolean</code>,
 						<code class="code">Collection</code>,
 						<code class="code">Integer</code>,
 						<code class="code">Lambda</code>,
 						<code class="code">OclAny</code>,
 						<code class="code">OclInvalid</code>,
 						<code class="code">OclMessage</code>,
 						<code class="code">OclSelf</code>,
 						<code class="code">OclVoid</code>,
 						<code class="code">OrderedSet</code>,
 						<code class="code">Real</code>,
 						<code class="code">Sequence</code>,
 						<code class="code">Set</code>,
 						<code class="code">String</code>,
 						<code class="code">Tuple</code>,
 						<code class="code">UnlimitedNatural</code>. An UnrestrictedName can be used in any context. The reserved type names can be used following a
 						<code class="code">::</code> qualification, Without qualification unrestricted names must be escaped as
 						<code class="code">_'Boolean'</code>.
 					</p>
 <p>

 <code class="code">Lambda</code> is used in experimental syntax that realizes iterator bodies as lambda-expressions.
 					</p>
 </div>
 </div>
 </div>
 <div class="section" title="The OCLinEcore Language">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OCLinEcore"></a>The OCLinEcore Language</h2>
 </div>
 </div>
 </div>
 <p>Ecore Abstract Syntax supports the use of OCL embedded within EAnnotations.</p>
 <p>The OCLinEcore language provides a textual Concrete Syntax that makes both Ecore and OCL accessible to users. Examples may be found in
 				<a class="link" href="#OCLinEcoreMetamodel" title="Edit Ecore Model as OCLinEcore">OCLinEcore Library Metamodel</a> and

 				<a class="link" href="#OCLinEcoreTutorialHelpers" title="Helper Features and Operations">OCLinEcore Helpers</a>.
 			</p>
 <p>The OCLinEcore tooling provides a rich editing environment based on Xtext with strong semantic checking.</p>
 <p>OCLinEcore is more than just an editor for OCL in Ecore, it is useful for</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>providing a coherent textual view of an Ecore meta-model</p>
 </li>
 <li class="listitem">
 <p>providing syntax sugar for some Ecore conventions</p>
 </li>
 <li class="listitem">
 <p>editing and validating OCL</p>
 </li>
 <li class="listitem">
 <p>integrating OCL into Ecore</p>
 </li>
 </ul>
 </div>
 <p>It is planned to take the syntactic sugar further and provide full support for all class-related UML concepts. The language therefore uses UML as its point of reference wherever possible.</p>
 <p>The OCLinEcore tooling may be used directly on *.ecore files, or on their *.oclinecore textual counterparts.</p>
 <p>Please follow the
 				<a class="link" href="#OCLinEcoreTutorial" title="OCLinEcore tutorial">OCLinEcore tutorial</a> for an introduction to the language and its tooling.
 			</p>
 <div class="section" title="Syntax">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Syntax2"></a>Syntax</h3>
 </div>
 </div>
 </div>
 <p>The OCLinEcore syntax has a consistent structure influenced by the informal definitions in OMG specifications and by the Ecore hierarchy. Most Ecore concepts are represented by a syntax of the form:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>optional primary adjectives</p>
 </li>
 <li class="listitem">
 <p>mandatory keyword</p>
 </li>
 <li class="listitem">
 <p>mandatory name facet</p>
 </li>
 <li class="listitem">
 <p>further facets</p>
 </li>
 <li class="listitem">
 <p>an optional braced clause of secondary adjectives</p>
 </li>
 <li class="listitem">
 <p>an optional braced clause of elements</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>composed elements</p>
 </li>
 <li class="listitem">
 <p>annotations</p>
 </li>
 <li class="listitem">
 <p>constraints</p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>Thus in:</p>
 <div class="literallayout">
 <p>
 <code class="code">abstract&nbsp;class&nbsp;Example&nbsp;extends&nbsp;Base&nbsp;{&nbsp;interface&nbsp;}&nbsp;{&nbsp;...&nbsp;}<br>

 </code>
 </p>
 </div>
 <p></p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">abstract</code> is a primary adjective
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">class</code> is a keyword
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">Example</code> is the name facet
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">extends Base</code> is a further facet
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">{ interface }</code> supports the secondary interface adjective.
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">{ ... }</code> provides a nested context for class content.
 						</p>
 </li>
 </ul>
 </div>
 <div class="section" title="Grammar Implementation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="GrammarImplementation2"></a>Grammar Implementation</h4>
 </div>
 </div>
 </div>
 <p>The grammar used by the Xtext editors may be found at:</p>
 <p>/src/org/eclipse/ocl/examples/xtext/oclinecore/OCLinEcore.xtext</p>
 <p>in the org.eclipse.ocl.xtext.oclinecore plugin. The OCLinEcore grammar extends the Essential OCL grammar.</p>
 </div>
 <div class="section" title="Module">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Module"></a>Module</h4>
 </div>
 </div>
 </div>
 <p>The Module syntax supports the overall structure of an Ecore file</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-rootpackage.png"></div>
 <p>

 </p>
 <p>The definition of the module comprises</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>optional module declaration</p>
 </li>
 <li class="listitem">
 <p>optional specification of the OCL Standard libraries</p>
 </li>
 <li class="listitem">
 <p>optional import of referenced Ecore or UML or OCLinEcore resources</p>
 </li>
 <li class="listitem">
 <p>a hierarchy of
 								<a class="link" href="#OCLinEcore-Package" title="Package">Packages</a>

 </p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-library.png"></div>
 <p>

 </p>
 <p>Zero or more external libraries may be imported so that their definitions are merged to form a composite library of basic and extended evaluation capability.</p>
 <p>The implicit import of the default OCL Standard Library is suppressed, if any library is imported. The default library may be extended by specifying it as the first library import.</p>
 <div class="literallayout">
 <p>
 <code class="code">library&nbsp;ocl&nbsp;:&nbsp;'http://www.eclipse.org/ocl/3.1.0/OCL.oclstdlib'<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The namespace URI of the first library package defines the namespace URI of the composite library. The namespace URI of subsequent library imports may not conflict, but may be null.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-import.png"></div>
 <p>

 </p>
 <p>Zero or more external metamodels may be imported.</p>
 </div>
 <div class="section" title="Package">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Package"></a>Package</h4>
 </div>
 </div>
 </div>
 <p>The Package syntax supports a nested hierarchy of packages and classifiers </p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-package1.png"></div>
 <p>

 </p>
 <p>A Package has a name and optionally a namespace prefix and namespace URI.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-package2.png"></div>
 <p>

 </p>
 <p>The content of a Package may comprise
 						<a class="link" href="#OCLinEcore-Package" title="Package">Packages</a>,
 						<a class="link" href="#OCLinEcore-Classifier" title="Classifier">Classifiers</a> and
 						<a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotations</a>.
 					</p>
 </div>
 <div class="section" title="Classifier">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Classifier"></a>Classifier</h4>
 </div>
 </div>
 </div>
 <p>The Classifier syntax supports the definition of types within a
 						<a class="link" href="#OCLinEcore-Package" title="Package">Package</a>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-classifiers.png"></div>
 <p>

 </p>
 <p>A Classifier may be</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>a
 								<a class="link" href="#OCLinEcore-Class" title="Class">Class</a>

 </p>
 </li>
 <li class="listitem">
 <p>a
 								<a class="link" href="#OCLinEcore-DataType" title="DataType">DataType</a>

 </p>
 </li>
 <li class="listitem">
 <p>an
 								<a class="link" href="#OCLinEcore-Enumeration" title="Enumeration">Enumeration</a> with associated
 								<a class="link" href="#OCLinEcore-EnumerationLiteral" title="EnumerationLiteral">EnumerationLiterals</a>

 </p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="DataType">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-DataType"></a>DataType</h4>
 </div>
 </div>
 </div>
 <p>The DataType syntax supports the definition of an EDataType.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-datatype1.png"></div>
 <p>

 </p>
 <p>A DataType has a name and optionally template parameters and an instance class name.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-datatype2.png"></div>
 <p>

 </p>
 <p>A DataType may be serializable; by default it is not.</p>
 <p>The content of a DataType may comprise
 						<a class="link" href="#OCLinEcore-Constraint" title="Constraints">invariants</a> and
 						<a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotations</a>.
 					</p>
 </div>
 <div class="section" title="Enumeration">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Enumeration"></a>Enumeration</h4>
 </div>
 </div>
 </div>
 <p>The Enumeration syntax supports the definition of an EEnum.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-enumeration1.png"></div>
 <p>

 </p>
 <p>An Enumeration has a name and optionally template parameters and an instance class name.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-enumeration2.png"></div>
 <p>

 </p>
 <p>An Enumeration may be serializable; by default it is not.</p>
 <p>The content of an Enumeration may comprise enumeration literals,
 						<a class="link" href="#OCLinEcore-Constraint" title="Constraints">invariants</a> and
 						<a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotations</a>.
 					</p>
 </div>
 <div class="section" title="EnumerationLiteral">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-EnumerationLiteral"></a>EnumerationLiteral</h4>
 </div>
 </div>
 </div>
 <p>The EnumerationLiteral syntax supports the definition of an EEnumLiteral.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-enumerationliteral.png"></div>
 <p>

 </p>
 <p>An EnumerationLiteral has a name and optionally a value.</p>
 <p>The content of an EnumerationLiteral may comprise
 						<a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotations</a>.
 					</p>
 </div>
 <div class="section" title="Class">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Class"></a>Class</h4>
 </div>
 </div>
 </div>
 <p>The Class syntax supports the definition of an EClass.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>optional abstract prefix</p>
 </li>
 <li class="listitem">
 <p>optional extension of other classifiers</p>
 </li>
 <li class="listitem">
 <p>optional invariants, annotations, features and operations</p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-class1.png"></div>
 <p>

 </p>
 <p>A Class may be abstract has a name and optionally template parameters.</p>
 <p>(NB, the &lsquo;abstract&rsquo; prefix is optional, even though the figure indicates that it is mandatory.)</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-class2.png"></div>
 <p>

 </p>
 <p>A Class may extend one or more other
 						<a class="link" href="#OCLinEcore-TypeRef" title="Types">Classes</a> that may be specialized using the template parameters.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-class3.png"></div>
 <p>

 </p>
 <p>A Class may have an instance class name, and may also be declared to be an interface.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-class4.png"></div>
 <p>

 </p>
 <p>The content of a Class may comprise
 						<a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotations</a>,
 						<a class="link" href="#OCLinEcore-Operation" title="Operation">Operations</a>,
 						<a class="link" href="#OCLinEcore-StructuralFeature" title="StructuralFeature">StructuralFeatures</a> and
 						<a class="link" href="#OCLinEcore-Constraint" title="Constraints">invariants</a>.
 					</p>
 </div>
 <div class="section" title="StructuralFeature">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-StructuralFeature"></a>StructuralFeature</h4>
 </div>
 </div>
 </div>
 <p>The StructuralFeature syntax supports the definition of the StructuralFeatures.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-features.png"></div>
 <p>

 </p>
 <p>A StructuralFeature may be</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>an
 								<a class="link" href="#OCLinEcore-Attribute" title="Attribute">Attribute</a>

 </p>
 </li>
 <li class="listitem">
 <p>a
 								<a class="link" href="#OCLinEcore-Reference" title="Reference">Reference</a>

 </p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Attribute">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Attribute"></a>Attribute</h4>
 </div>
 </div>
 </div>
 <p>The Attribute syntax supports the definition of an EAttribute; a Property with a DataType value.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-attribute1.png"></div>
 <p>

 </p>
 <p>An Attribute may be static and has a name.</p>
 <p>The
 						<code class="code">static</code> qualifier supports declaration of static properties which are supported by UML and OCL. Note that Ecore does not support static properties.
 					</p>
 <p>The
 						<code class="code">definition</code> qualifier is an obsolete experimental syntax for Complete OCL definitions.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-attribute2.png"></div>
 <p>

 </p>
 <p>An Attribute may may have a
 						<a class="link" href="#OCLinEcore-TypeRef" title="Types">Type</a> and multiplicity.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-attribute3.png"></div>
 <p>

 </p>
 <p>An Attribute may a simple initializer and a variety of qualifiers:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">derived</code> specifies a derived attribute (default
 								<code class="code">!derived</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">id</code> specifies that the attribute provides the identifier if its class (default
 								<code class="code">!id</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">ordered</code> specifies that the attribute elements are ordered (default
 								<code class="code">!ordered</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">readonly</code> specifies that the attribute elements are readonly (not changeable) (default
 								<code class="code">!readonly</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">transient</code> specifies that the attribute elements are computed on the fly (default
 								<code class="code">!transient</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">unique</code> specifies that there are no duplicate attribute elements (default
 								<code class="code">unique</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">unsettable</code> specifies that attribute element may have no value (default
 								<code class="code">!unsettable</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">volatile</code> specifies that the attribute elements are not persisted (default
 								<code class="code">!volatile</code>)
 							</p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-attribute4.png"></div>
 <p>

 </p>
 <p>The content of an Attribute may comprise
 						<a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotations</a>, initial and derived
 						<a class="link" href="#OCLinEcore-Constraint" title="Constraints">constraints</a>.
 					</p>
 <p>A simple constant value may be defined using the initializer. A computed value requires the use of a constraint. If both initial and derived constraints are present, the initial constraint is ignored.</p>
 <p>The defaults for multiplicity lower and upper bound and for
 						<code class="code">ordered</code> and
 						<code class="code">unique</code> follow the UML specification and so corresponds to a single element Set that is
 						<code class="code">[1] {unique,!ordered}</code>.
 						Note that UML defaults differ from the Ecore defaults which correspond to an optional element OrderedSet, that is
 						<code class="code">[?] {ordered,unique}</code>.
 					</p>
 </div>
 <div class="section" title="Reference">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Reference"></a>Reference</h4>
 </div>
 </div>
 </div>
 <p>The Reference syntax supports the definition of an EReference; a Property with a Class value.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-reference1.png"></div>
 <p>

 </p>
 <p>An Reference may be static and has a name and optionally an opposite name.</p>
 <p>The
 						<code class="code">static</code> qualifier supports declaration of static properties which are supported by UML and OCL. Note that Ecore does not support static properties.
 					</p>
 <p>The
 						<code class="code">definition</code> qualifier is an obsolete experimental syntax for Complete OCL definitions.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-reference2.png"></div>
 <p>

 </p>
 <p>A Reference may may have a
 						<a class="link" href="#OCLinEcore-TypeRef" title="Types">Type</a> and multiplicity.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-reference3.png"></div>
 <p>

 </p>
 <p>A Reference may a simple initializer and a variety of qualifiers:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">composes</code> specifies a composed (containing) reference (default
 								<code class="code">!composes</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">derived</code> specifies a derived reference (default
 								<code class="code">!derived</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">ordered</code> specifies that the reference elements are ordered (default
 								<code class="code">!ordered</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">readonly</code> specifies that the reference elements are readonly (not changeable) (default
 								<code class="code">!readonly</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">resolve</code> specifies that the reference elements proxies may need resolution (default
 								<code class="code">!resolve</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">transient</code> specifies that the reference elements are computed on the fly (default
 								<code class="code">!transient</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">unique</code> specifies that there are no duplicate reference elements (default
 								<code class="code">unique</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">unsettable</code> specifies that reference element may have no value (default
 								<code class="code">!unsettable</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">volatile</code> specifies that the reference elements are not persisted (default
 								<code class="code">!volatile</code>)
 							</p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-reference4.png"></div>
 <p>

 </p>
 <p>The content of a Reference may comprise keys,
 						<a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotations</a>, initial and derived
 						<a class="link" href="#OCLinEcore-Constraint" title="Constraints">constraints</a>.
 					</p>
 <p>A simple constant value may be defined using the initializer. A computed value requires the use of a constraint. If both initial and derived constraints are present, the initial constraint is ignored.</p>
 <p>The defaults for multiplicity lower and upper bound and for
 						<code class="code">ordered</code> and
 						<code class="code">unique</code> follow the UML specification and so corresponds to a single element Set that is
 						<code class="code">[1] {unique,!ordered}</code>.
 						Note that UML defaults differ from the Ecore defaults which correspond to an optional element OrderedSet, that is
 						<code class="code">[?] {ordered,unique}</code>.
 					</p>
 </div>
 <div class="section" title="Operation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Operation"></a>Operation</h4>
 </div>
 </div>
 </div>
 <p>The Operation syntax supports the definition of an EOperation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-operation1.png"></div>
 <p>

 </p>
 <p>An Operation may be static and has a name and optionally template parameters.</p>
 <p>The
 						<code class="code">static</code> qualifier supports declaration of static operations which are supported by UML and OCL. Note that Ecore does not support static operations.
 					</p>
 <p>The
 						<code class="code">definition</code> qualifier is an obsolete experimental syntax for Complete OCL definitions.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-operation2.png"></div>
 <p>

 </p>
 <p>An Operation has zero of more
 						<a class="link" href="#OCLinEcore-Parameter" title="Parameter">Parameters</a>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-operation3.png"></div>
 <p>

 </p>
 <p>An Operation may have a return
 						<a class="link" href="#OCLinEcore-TypeRef" title="Types">Type</a> and multiplicity.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-operation4.png"></div>
 <p>

 </p>
 <p>An Operation may declare zero or more throw
 						<a class="link" href="#OCLinEcore-TypeRef" title="Types">Exceptions</a>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-operation5.png"></div>
 <p>

 </p>
 <p>An Operation may have a variety of qualifiers:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">derived</code> specifies a derived operation (default
 								<code class="code">!derived</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">ordered</code> specifies that the returned elements are ordered (default
 								<code class="code">!ordered</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">unique</code> specifies that there are no duplicate returned elements (default
 								<code class="code">unique</code>)
 							</p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-operation6.png"></div>
 <p>

 </p>
 <p>The content of an Operation may comprise
 						<a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotations</a>, precondition, postcondition and body
 						<a class="link" href="#OCLinEcore-Constraint" title="Constraints">constraints</a>.
 					</p>
 <p>The
 						<code class="code">static</code> qualifier supports declaration of static operations which are supported by UML and OCL. Note that Ecore does not support static operations.
 					</p>
 <p>The
 						<code class="code">definition</code> qualifier is an obsolete experimental syntax for Complete OCL definitions.
 					</p>
 <p>The defaults for multiplicity lower and upper bound and for
 						<code class="code">ordered</code> and
 						<code class="code">unique</code> follow the UML specification and so corresponds to a single element Set that is
 						<code class="code">[1] {unique,!ordered}</code>.
 						Note that UML defaults differ from the Ecore defaults which correspond to an optional element OrderedSet, that is
 						<code class="code">[?] {ordered,unique}</code>.
 					</p>
 </div>
 <div class="section" title="Parameter">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Parameter"></a>Parameter</h4>
 </div>
 </div>
 </div>
 <p>The Parameter syntax supports the definition of an EParameter.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-parameter1.png"></div>
 <p>

 </p>
 <p>A Parameter has a name, optional "Type:#OCLinEcore-TypeRef and multiplicity</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-parameter2.png"></div>
 <p>

 </p>
 <p>A Parameter may have a variety of qualifiers:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">ordered</code> specifies that the returned elements are ordered (default
 								<code class="code">!ordered</code>)
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">unique</code> specifies that there are no duplicate returned elements (default
 								<code class="code">unique</code>)
 							</p>
 </li>
 </ul>
 </div>
 <p>The content of a Parameter may comprise
 						<a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotations</a>.
 					</p>
 <p>The defaults for multiplicity lower and upper bound and for
 						<code class="code">ordered</code> and
 						<code class="code">unique</code> follow the UML specification and so corresponds to a single element Set that is
 						<code class="code">[1] {unique,!ordered}</code>.
 						Note that UML defaults differ from the Ecore defaults which correspond to an optional element OrderedSet, that is
 						<code class="code">[?] {ordered,unique}</code>.
 					</p>
 </div>
 <div class="section" title="Types">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-TypeRef"></a>Types</h4>
 </div>
 </div>
 </div>
 <p>The Type syntax supports the definition of EType and EGenericType in conjunction with an ETypedElement. The syntax is very similar to Java.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-types.png"></div>
 <p>

 </p>
 <p>

 <span class="emphasis"><em>PrimitiveTypeRefCS</em></span> provides access to the built-in OCL types and their corrersponding Ecore counterparts
 					</p>
 <table id="N10D05">
 <tr>

 <th>OCL type</th>
 							<th>Ecore type</th>

 </tr>
 <tr>

 <td>Boolean</td>
 							<td>EBoolean</td>

 </tr>
 <tr>

 <td>Integer</td>
 							<td>EBigInteger</td>

 </tr>
 <tr>

 <td>Real</td>
 							<td>EBigDecimal</td>

 </tr>
 <tr>

 <td>String</td>
 							<td>EString</td>

 </tr>
 <tr>

 <td>UnlimitedNatural</td>
 							<td>EBigInteger</td>

 </tr>
 </table>
 <p>

 <span class="emphasis"><em>TypedTypeRefCS</em></span> provides for user defined types and their template parameterisation.
 					</p>
 </div>
 <div class="section" title="AnnotationElement">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Annotations"></a>AnnotationElement</h4>
 </div>
 </div>
 </div>
 <p>The AnnotationElement syntax supports the definition of an EAnnotation hierarchy with details, references and contents.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-annotations.png"></div>
 <p>

 </p>
 <p>An AnnotationElement may be
 						<a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotation</a> or
 						<a class="link" href="#OCLinEcore-Documentation" title="Documentation">Documentation</a>.
 					</p>
 </div>
 <div class="section" title="Annotation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Annotation"></a>Annotation</h4>
 </div>
 </div>
 </div>
 <p>The Annotation syntax supports the definition of an EAnnotation hierarchy with details, references and contents.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-annotation1.png"></div>
 <p>

 </p>
 <p>An Annotation has a source URI, which may be specified without quotes if the URI is just a name.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-annotation2.png"></div>
 <p>

 </p>
 <p>An Annotation may have
 						<a class="link" href="#OCLinEcore-Detail" title="Detail">Details</a>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-annotation3.png"></div>
 <p>

 </p>
 <p>The content of an Annotation may comprise</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#OCLinEcore-Annotation" title="Annotation">Annotations</a>

 </p>
 </li>
 <li class="listitem">
 <p>content elements</p>
 </li>
 <li class="listitem">
 <p>names that reference other elements</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Detail">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Detail"></a>Detail</h4>
 </div>
 </div>
 </div>
 <p>The Detail syntax supports the definition of a detail of an EAnnotation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-detail.png"></div>
 <p>

 </p>
 <p>A detail comprises a detail key and optional value.</p>
 </div>
 <div class="section" title="Documentation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Documentation"></a>Documentation</h4>
 </div>
 </div>
 </div>
 <p>The Documentation syntax is an experimental syntactic sugar for a genmodel annotation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-annotations.png"></div>
 <p>

 </p>
 <p>It is likely to be replaced by a Javadoc-style comment that will be persisted in Ecore.</p>
 </div>
 <div class="section" title="Constraints">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcore-Constraint"></a>Constraints</h4>
 </div>
 </div>
 </div>
 <p>The Constraints syntax supports the embedding of OCL expressions as invariants for classes, as preconditions, postconditions or bodies for operations and initial or derived values for properties.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-constraints.png"></div>
 <p>

 </p>
 <p>The integration occurs through the
 						<span class="emphasis"><em>SpecificationCS</em></span> rule that invokes an
 						<a class="link" href="#EssentialOCL-Exp" title="OCL Expression">ExpCS</a>. (The alternative
 						<span class="emphasis"><em>UnquotedString</em></span> is an implementation detail that supports the import from Ecore where the OCL is in unparsed textual form rather than an analyzed syntax tree.)
 					</p>
 <p>A class invariant may be
 						<code class="code">callable</code> to specify that the Ecore representation is to use the EOperation rather than EAnnotation representation.
 					</p>
 <p>A class invariant optionally supports a second OCL expression as a parenthesis on the invariant name. This parenthesized expression is invoked when an invariant fails in order to provide a user-defined failure message. Whether this message is an error or a warning is determined by the evaluation of the invariant:</p>
 </div>
 <div class="section" title="Terminals">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Terminals"></a>Terminals</h4>
 </div>
 </div>
 </div>
 <p>The OCLinEcore grammar extens the Esstial OCL grammar which should be consulted for definition of INT, and ExpCS.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1200-terminals.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Names">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Names"></a>Names </h4>
 </div>
 </div>
 </div>
 <p>An Unrestricted name is any name other than the OCL reserved keywords. See
 						<a class="link" href="#EssentialOCL-UnrestrictedName" title="UnrestrictedName">UnrestrictedName</a>.
 					</p>
 <p>An Unreserved name is any name other than the OCL reserved keywords above or the OCL reserved types. See
 						<a class="link" href="#EssentialOCL-UnreservedName" title="UnreservedName">UnreservedName</a>.
 					</p>
 <p>If you need to use any of these names or non-alphanumeric names, you must use the escaped string syntax for a name: e.g.
 						<code class="code">_'true'</code>. The usual Java backslash escapes, with the exception of octal are supported:
 						<code class="code">_'new-lines\n\x0a\u000a'</code>

 </p>
 </div>
 <div class="section" title="Comments">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Comments"></a>Comments</h4>
 </div>
 </div>
 </div>
 <p>Single line comments are supported by ignoring all text following
 						<code class="code">--</code>.
 					</p>
 <p>Multi line comments are supported by ignoring all text within
 						<code class="code">/* ... */</code>.
 					</p>
 <p>Documentation comments are supported for all text within
 						<code class="code">/** ... */</code>. Unfortunately no documentation EAnnotation is currently created.
 					</p>
 </div>
 </div>
 <div class="section" title="Limitations">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Limitations"></a>Limitations</h3>
 </div>
 </div>
 </div>
 <p>OCLinEcore supports the full capabilities of Ecore, however the support for upper and lower bounds on generic types has not been adequately tested.</p>
 <p>OCLinEcore provides primary syntaxes for some Ecore conventions such as genmodel annotations and constraints; much more support is needed for feature maps.</p>
 </div>
 </div>
 <div class="section" title="The Complete OCL Language">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="CompleteOCL"></a>The Complete OCL Language</h2>
 </div>
 </div>
 </div>
 <p>The Complete OCL provides a language for a document in which OCL complements an existing meta-model with invariants, and additional features.</p>
 <div class="section" title="Syntax">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Syntax3"></a>Syntax</h3>
 </div>
 </div>
 </div>
 <p>The Complete OCL syntax is defined by the OMG OCL 2.4 specification.</p>
 <p>The syntax comprises keywords such as
 					<code class="code">context</code> followed by appropriate names and punctuation and OCL expressions.
 				</p>
 <p>With the exception of
 					<code class="code">endpackage</code> there is no terminating punctuation and so the consequences of a syntax error can be quite far-reaching while editing a document. Concentrate on the first error.
 				</p>
 <p>A substantial example of Complete OCL may be found by installing the
 					<a class="link" href="#RoyalAndLoyalExample" title="Royal and Loyal Example Project">RoyalAndLoyal Example Project</a>.
 				</p>
 <div class="section" title="Grammar Implementation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="GrammarImplementation3"></a>Grammar Implementation</h4>
 </div>
 </div>
 </div>
 <p>The grammar used by the Xtext editors may be found at:</p>
 <p>/src/org/eclipse/ocl/examples/xtext/completeocl/CompleteOCL.xtext</p>
 <p>in the org.eclipse.ocl.xtext.completeocl plugin. The Complete OCL grammar extends the Essential OCL grammar.</p>
 </div>
 <div class="section" title="Complete OCL Document">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-Document"></a>Complete OCL Document</h4>
 </div>
 </div>
 </div>
 <p>The Document syntax defines a Complete OCL document, for which *.ocl is the default extension.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-document.png"></div>
 <p>

 </p>
 <p>A Complete OCL document may</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>import meta-models to be complemented</p>
 </li>
 <li class="listitem">
 <p>include additional Complute OCL documents</p>
 </li>
 <li class="listitem">
 <p>specify one or more Standard Library documents</p>
 </li>
 </ul>
 </div>
 <p>and then provide complements for one of more Packages, Classifiers or Features.</p>
 <p>The import, include and library declarations are Eclipse OCL extensions. The OCL 2.4 specification provides no mechanism for a Complete OCL document to reference external material.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-import.png"></div>
 <p>

 </p>
 <p>The primary definitions of each meta-model may be imported by specifying the URI of a Package and optionally an alias for that Package.</p>
 <p>The import may be from a *.ecore, *.uml or *.oclinecore file.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-include.png"></div>
 <p>

 </p>
 <p>Additional documents complementing meta-model may be included by specifying the URI of the Complete OCL document.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-library.png"></div>
 <p>

 </p>
 <p>Zero or more external libraries may be imported so that their definitions are merged to form a composite library of basic and extended evaluation capability.</p>
 <p>The implicit import of the default OCL Standard Library is suppressed, if any library is imported. The default library may be extended by specifying it as the first library import.</p>
 <div class="literallayout">
 <p>
 <code class="code">library&nbsp;ocl&nbsp;:&nbsp;'http://www.eclipse.org/ocl/3.1.0/OCL.oclstdlib'<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The namespace URI of the first library package defines the namespace URI of the composite library. The namespace URI of subsequent library imports may not conflict, but may be null.</p>
 </div>
 <div class="section" title="PackageDeclaration">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-PackageDeclaration"></a>PackageDeclaration</h4>
 </div>
 </div>
 </div>
 <p>The PackageDeclaration syntax identifies a Package to be complemented.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-packagedeclaration1.png"></div>
 <p>

 </p>
 <p>The package keyword is followed by the optionally qualified name of the package to be complemented.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-packagedeclaration2.png"></div>
 <p>

 </p>
 <p>The name is followed by the
 						<a class="link" href="#CompleteOCL-ContextDecl" title="ContextDecl">declaration contexts</a> to be complemented and finally an endpackage keyword.
 					</p>
 </div>
 <div class="section" title="ContextDecl">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-ContextDecl"></a>ContextDecl</h4>
 </div>
 </div>
 </div>
 <p>The ContextDecl syntax identifies a model element to be complemented.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-contextdecl.png"></div>
 <p>

 </p>
 <p>A complemented context may be a</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#CompleteOCL-ClassifierContextDecl" title="ClassifierContextDecl">Classifier Context</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#CompleteOCL-OperationContextDecl" title="OperationContextDecl">Operation Context</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#CompleteOCL-PropertyContextDecl" title="PropertyContextDecl">Property Context</a>

 </p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="ClassifierContextDecl">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-ClassifierContextDecl"></a>ClassifierContextDecl</h4>
 </div>
 </div>
 </div>
 <p>The ClassifierContextDecl syntax identifies a Classifier to be complemented.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-classifiercontextdecl1.png"></div>
 <p>

 </p>
 <p>The context keyword is followed by an optional declaration of the name of the context variable. If omitted the context variable is named
 						<code class="code">self</code>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-classifiercontextdecl2.png"></div>
 <p>

 </p>
 <p>Then the optionally qualified name of the classifier to be complemented is defined. Qualification is required if the classifier context is specified directly as part of the document. Qualification may be omitted when the classifier context is specified as part of a package declaration.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-classifiercontextdecl3.png"></div>
 <p>

 </p>
 <p>Finally the content of the classifier context may comprise</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#CompleteOCL-Def" title="Def">Def</a> to define an additional feature
 							</p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#CompleteOCL-Inv" title="Inv">Inv</a> to define an invariant
 							</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Def">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-Def"></a>Def</h4>
 </div>
 </div>
 </div>
 <p>The Def syntax defines an additional Feature for a Classifier.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-def1.png"></div>
 <p>

 </p>
 <p>The definition may define a static feature with a feature name.</p>
 <p>A further name may be specified for no very obvious purpose other than symmetry with an invariant. The optional name is not used.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-def2.png"></div>
 <p>

 </p>
 <p>A parenthesized
 						<a class="link" href="#CompleteOCL-Parameter" title="Parameter">parameter</a> list must be specified to define an operation and omitted for a property definition.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-def3.png"></div>
 <p>

 </p>
 <p>Then the property or optional operation return
 						<a class="link" href="#EssentialOCL-TypeExp" title="TypeExp">type</a> is specified followed by the
 						<a class="link" href="#CompleteOCL-Specification" title="Specification">specification</a> of the property initializer or operation body.
 					</p>
 <p>An additional definition is usable within an OCL expression as if it was defined in the complemented meta-model. For the purposes of reflection the additional appear as part of the complemented meta-model, however they remain complements and are not persisted with that meta-model.</p>
 </div>
 <div class="section" title="Inv">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-Inv"></a>Inv</h4>
 </div>
 </div>
 </div>
 <p>The Inv syntax defines an invariant for a Classifier.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-inv.png"></div>
 <p>

 </p>
 <p>The inv keyword is followed by an optional invariant name an optional violation message and the
 						<a class="link" href="#CompleteOCL-Specification" title="Specification">specification</a> of the invariant.
 					</p>
 <p>The optional name may be used by validation environments to identify the invariant in a control panel and in diagnostic messages.</p>
 <p>The optional violation message provides an OCL expression that may be used by a validation environment to provide a custom message to explain a broken invariant. The severity of the invariant violationm may be controlled by the value of the invariant expression.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>true indicates that the invariant was satisfied</p>
 </li>
 <li class="listitem">
 <p>false indicates that the invariant was violated with warning severity</p>
 </li>
 <li class="listitem">
 <p>null indicates that the invariant was violated with error severity</p>
 </li>
 <li class="listitem">
 <p>invalid indicates that the invariant failed to evaluate</p>
 </li>
 </ul>
 </div>
 <p>In the Indigo release, the local variables of the invariant are not accessible to the violation message expression. This will be changed in a future release.</p>
 <p>In the Indigo release, custom messages are available when a CompleteOCLEObjectValidator is used as the EValidator. This is not the case for validation in the Sample Ecore Editor and so a default message using the invariant name and the failing object is provided. </p>
 </div>
 <div class="section" title="OperationContextDecl">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-OperationContextDecl"></a>OperationContextDecl</h4>
 </div>
 </div>
 </div>
 <p>The OperationContextDecl syntax identifies an Operation to be complemented.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-operationcontextdecl1.png"></div>
 <p>

 </p>
 <p>The context keyword is followed by the optionally qualified name of the operation to be complemented. Qualification is always required since the operation context may be specified as part of the document or a package declaration but not a classifier.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-operationcontextdecl2.png"></div>
 <p>

 </p>
 <p>The name is followed by a parenthesized
 						<a class="link" href="#CompleteOCL-Parameter" title="Parameter">parameter</a> list.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-operationcontextdecl3.png"></div>
 <p>

 </p>
 <p>Finally an optional return
 						<a class="link" href="#EssentialOCL-TypeExp" title="TypeExp">type</a> and the operation constraints are specified. The operation constraints may comprise
 					</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>a
 								<a class="link" href="#CompleteOCL-Body" title="Body">Body</a> to define operation body
 							</p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#CompleteOCL-Inv" title="Inv">Pre</a> to define a precondition on the operation
 							</p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#CompleteOCL-Inv" title="Inv">Post</a> to define a postcondition on the operation
 							</p>
 </li>
 </ul>
 </div>
 <p>Any number of preconditions and postconditions can be specified. Only one body is permitted.</p>
 </div>
 <div class="section" title="Parameter">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-Parameter"></a>Parameter</h4>
 </div>
 </div>
 </div>
 <p>The Parameter syntax identifies a Parameter of an Operation to be complemented.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-parameter.png"></div>
 <p>

 </p>
 <p>A parameter comprises an optional name and Essential OCL
 						<a class="link" href="#EssentialOCL-TypeExp" title="TypeExp">type</a> declaration.
 					</p>
 <p>The parameter name may be omitted for
 						<a class="link" href="#CompleteOCL-OperationContextDecl" title="OperationContextDecl">Operation Contexts</a> if the parameter name is not used by any of the constraints.
 					</p>
 <p>The parameter name is required for
 						<a class="link" href="#CompleteOCL-Def" title="Def">Operation Definitions</a>.
 					</p>
 <p>Note that the type declarations are Essential OCL types such as
 						<code class="code">Sequence&lt;String&gt;</code> rather than UML&rsquo;s and OCLinEcore&rsquo;s
 						<code class="code">String[*] {ordered !unique}</code>. There are plans to unify these syntaxes.
 					</p>
 </div>
 <div class="section" title="Body">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-Body"></a>Body</h4>
 </div>
 </div>
 </div>
 <p>The Body syntax defines the body for a complemented Operation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-body.png"></div>
 <p>

 </p>
 <p>The body keyword is followed by an optional name and the body
 						<a class="link" href="#CompleteOCL-Specification" title="Specification">specification</a>.
 					</p>
 <p>The optional name is not used.</p>
 </div>
 <div class="section" title="Post">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-Post"></a>Post</h4>
 </div>
 </div>
 </div>
 <p>The Post syntax defines a postcondition for a complemented Operation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-post.png"></div>
 <p>

 </p>
 <p>The post keyword is followed by an optional name and the postcondition
 						<a class="link" href="#CompleteOCL-Specification" title="Specification">specification</a>.
 					</p>
 <p>The optional name may be used by a validation environment to identify a failing postcondition.</p>
 <p>The Indigo release parses and persists postconditions but does not evaluate them.</p>
 </div>
 <div class="section" title="Pre">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-Pre"></a>Pre</h4>
 </div>
 </div>
 </div>
 <p>The Pre syntax defines a precondition for a complemented Operation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-pre.png"></div>
 <p>

 </p>
 <p>The pre keyword is followed by an optional name and the precondition
 						<a class="link" href="#CompleteOCL-Specification" title="Specification">specification</a>.
 					</p>
 <p>The optional name may be used by a validation environment to identify a failing precondition.</p>
 <p>The Indigo release parses and persists preconditions but does not evaluate them.</p>
 </div>
 <div class="section" title="PropertyContextDecl">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-PropertyContextDecl"></a>PropertyContextDecl</h4>
 </div>
 </div>
 </div>
 <p>The PropertyContextDecl syntax identifies a Property to be complemented.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-propertycontextdecl1.png"></div>
 <p>

 </p>
 <p>The context keyword is followed by the optionally qualified name of the property to be complemented. Qualification is always required since the property context may be specified as part of the document or a package declaration but not a classifier.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-propertycontextdecl2.png"></div>
 <p>

 </p>
 <p>Finally the property
 						<a class="link" href="#EssentialOCL-TypeExp" title="TypeExp">type</a> and the property constraints are specified. The property constraints may comprise
 					</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>an
 								<a class="link" href="#CompleteOCL-Init" title="Init">Init</a> to specify an initialization
 							</p>
 </li>
 <li class="listitem">
 <p>a
 								<a class="link" href="#CompleteOCL-Der" title="Der">Der</a> to specify a derivation
 							</p>
 </li>
 </ul>
 </div>
 <p>An initialization is specified to define the property value when the property is created.</p>
 <p>A derivation is specified to define the property value at all times.</p>
 <p>It does not therefore make sense to specify both an an initial and an all-time value. If both are specified the derivation is used.</p>
 </div>
 <div class="section" title="Init">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-Init"></a>Init</h4>
 </div>
 </div>
 </div>
 <p>The Init syntax defines an initial value for a complemented Property.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-init.png"></div>
 <p>

 </p>
 <p>The init keyword and colon are followed by the initial value
 						<a class="link" href="#CompleteOCL-Specification" title="Specification">specification</a>.
 					</p>
 </div>
 <div class="section" title="Der">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-Der"></a>Der</h4>
 </div>
 </div>
 </div>
 <p>The Der syntax defines a derived value for a complemented Property.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-der.png"></div>
 <p>

 </p>
 <p>The der keyword and colon are followed by the derived value
 						<a class="link" href="#CompleteOCL-Specification" title="Specification">specification</a>.
 					</p>
 </div>
 <div class="section" title="Specification">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-Specification"></a>Specification</h4>
 </div>
 </div>
 </div>
 <p>The Specification syntax provides an OCL expression to specify some aspect of a complemented model.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-specification.png"></div>
 <p>

 </p>
 <p>The specification comprises and
 						<a class="link" href="#EssentialOCL-Exp" title="OCL Expression">Essential OCL Expression</a>.
 					</p>
 </div>
 <div class="section" title="NavigatingExp">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-NavigatingExp"></a>NavigatingExp</h4>
 </div>
 </div>
 </div>
 <p>The NavigatingExp syntax defines enhancements to the
 						<a class="link" href="#EssentialOCL-NavigatingExp" title="NavigatingExp">Essential OCL NavigatingExp</a> syntax.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-navigatingexp.png"></div>
 <p>

 </p>
 <p>The name of a model element may have a further @pre qualification for use within an operation postcondition. It allows the postcondition to access the value on entry to an operation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1300-navigatingarg.png"></div>
 <p>

 </p>
 <p>

 <code class="code">?</code> may be specified as the argument in a navigating expression to indicate unknown values when testing sent messages.
 					</p>
 </div>
 <div class="section" title="NavigationOperators">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-NavigationOperators"></a>NavigationOperators</h4>
 </div>
 </div>
 </div>
 <p>The
 						<a class="link" href="#EssentialOCL-NavigationOperators" title="NavigationOperators">Essential OCL NavigationOperators</a> are extended to support
 					</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">^</code> to test whether a message has been sent message
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">^^</code> to reference the content of a message
 							</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="UnreservedName">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-UnreservedName"></a>UnreservedName</h4>
 </div>
 </div>
 </div>
 <p>The Complete OCL reserved words are unchanged from Essential OCL, consequently a Complete OCL Unreserved name is the same as an
 						<a class="link" href="#EssentialOCL-UnreservedName" title="UnreservedName">Essential OCL UnreservedName</a>.
 					</p>
 </div>
 <div class="section" title="UnrestrictedName">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CompleteOCL-UnrestrictedName"></a>UnrestrictedName</h4>
 </div>
 </div>
 </div>
 <p>The Complete OCL has two additional built-in types:
 						<code class="code">OclMessage</code> and
 						<code class="code">OclState</code>. These names and the
 						<a class="link" href="#EssentialOCL-UnrestrictedName" title="UnrestrictedName">Essential OCL RestrictedNames</a> are not available without qualification or escaping.
 					</p>
 </div>
 </div>
 </div>
 <div class="section" title="The OCL Standard Library Language">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OCLstdlib"></a>The OCL Standard Library Language</h2>
 </div>
 </div>
 </div>
 <p>The OCL Standard Library Language is used to define the OCL Standard Library, for which *.oclstdlib is the default extension.</p>
 <p>The standard library can be replaced or extended.</p>
 <p>The source for the OCL Standard Library may be found at model/OCL-2.5.oclstdlib in the org.eclipse.ocl.library plugin. </p>
 <div class="section" title="Syntax">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Syntax4"></a>Syntax</h3>
 </div>
 </div>
 </div>
 <div class="section" title="Grammar Implementation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="GrammarImplementation4"></a>Grammar Implementation</h4>
 </div>
 </div>
 </div>
 <p>The grammar used by the Xtext editors may be found at:</p>
 <p>/src/org/eclipse/ocl/examples/xtext/oclstdlib/OCLstdlib.xtext</p>
 <p>in the org.eclipse.ocl.xtext.oclstdlib plugin. The OCL Standard Library grammar extends the Essential OCL grammar.</p>
 </div>
 <div class="section" title="OCL Standard Library Document">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Library"></a>OCL Standard Library Document</h4>
 </div>
 </div>
 </div>
 <p>The Library syntax defines an OCL Standard Library document, for which *.oclstdlib is the default extension.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-library1.png"></div>
 <p>

 </p>
 <p>Zero or more library documents may be imported for use within the composite library whose name must be specified.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-library2.png"></div>
 <p>

 </p>
 <p>A namespace prefix and namespace URI may optionally be specified.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-library3.png"></div>
 <p>

 </p>
 <p>The body of the document comprises</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>optional module declaration</p>
 </li>
 <li class="listitem">
 <p>optional specification of the OCL Standard libraries</p>
 </li>
 <li class="listitem">
 <p>optional import of referenced Ecore or UML or OCLinEcore resources</p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#OCLstdlib-Precedence" title="Precedence">Precedences</a>

 </p>
 </li>
 <li class="listitem">
 <p>a hierarchy of
 								<a class="link" href="#OCLstdlib-Package" title="Package">Packages</a>

 </p>
 </li>
 <li class="listitem">
 <p>a hierarchy of
 								<a class="link" href="#OCLstdlib-Classifier" title="Class and Classifier">Classifiers</a>

 </p>
 </li>
 <li class="listitem">
 <p>Annotations</p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-library.png"></div>
 <p>

 </p>
 <p>Zero or more external libraries may be imported so that their definitions are merged to form a composite library of basic and extended evaluation capability.</p>
 <p>The default library may be extended by specifying it as the first library import.</p>
 <div class="literallayout">
 <p>
 <code class="code">library&nbsp;'http://www.eclipse.org/ocl/3.1.0/OCL.oclstdlib'<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The namespace URI of the first library package defines the namespace URI of the composite library. The namespace URI of subsequent library imports may not conflict, but may be null.</p>
 </div>
 <div class="section" title="Precedence">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Precedence"></a>Precedence</h4>
 </div>
 </div>
 </div>
 <p>The Precedence syntax defines the precedence and associativity of infix operators.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-precedence.png"></div>
 <p>

 </p>
 <p>Each entry in a list of precedences names a precedence level taht can then be used by an infix operator. Each level can be either left or right associative.</p>
 <p>Multiple lists of precedence levels can be merged from imported libraries provided the lists are interleaveable with conflict or ambiguity.</p>
 </div>
 <div class="section" title="Package">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Package"></a>Package</h4>
 </div>
 </div>
 </div>
 <p>The Package syntax defines a nested hierarchy of packages and classifiers .</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-package1.png"></div>
 <p>

 </p>
 <p>A Package has a name and optionally a namespace prefix and namespace URI.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-package2.png"></div>
 <p>

 </p>
 <p>The content of a Package may comprise
 						<a class="link" href="#OCLstdlib-Package" title="Package">Packages</a>,
 						<a class="link" href="#OCLstdlib-Classifier" title="Class and Classifier">Classifiers</a> and Annotations.
 					</p>
 </div>
 <div class="section" title="Class and Classifier">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Classifier"></a>Class and Classifier</h4>
 </div>
 </div>
 </div>
 <p>The Class and Classifier syntax define a type within a Package.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-classifier.png"></div>
 <p>

 </p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-class1.png"></div>
 <p>

 </p>
 <p>A Class has a name and optionally template parameters. A class may also name the metatype such as
 						<code class="code">PrimitiveType</code> that the Class is an instance of.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-class2.png"></div>
 <p>

 </p>
 <p>A Class may extend one or more other Classes that may be specialized using the template parameters.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-class3.png"></div>
 <p>

 </p>
 <p>The content of a Class may comprise
 						<a class="link" href="#OCLstdlib-Operation" title="Operation">Operations</a>,
 						<a class="link" href="#OCLstdlib-Property" title="LibProperty">Properties</a>,
 						<a class="link" href="#OCLstdlib-Inv" title="Inv">Invariants</a> and Annotations.
 					</p>
 </div>
 <div class="section" title="Inv">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Inv"></a>Inv</h4>
 </div>
 </div>
 </div>
 <p>The Inv syntax defines an invariant constraint.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-inv.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Operation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Operation"></a>Operation</h4>
 </div>
 </div>
 </div>
 <p>The general Operation syntax defines a conventional Operation or Iteration.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-operation.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="LibOperation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-LibOperation"></a>LibOperation</h4>
 </div>
 </div>
 </div>
 <p>The LibOperation syntax defines a conventional Operation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-operation1.png"></div>
 <p>

 </p>
 <p>An Operation may be static and has a name and optionally template parameters.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-operation2.png"></div>
 <p>

 </p>
 <p>An Operation has zero of more
 						<a class="link" href="#OCLstdlib-Parameter" title="Parameter">Parameters</a>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-operation3.png"></div>
 <p>

 </p>
 <p>An Operation has a return Type. An infix operation may specify a precedence level. An operation may specify the name of a Java class implementing the org.eclipse.ocl.library.LibraryOperation interface. This class is used when evaluating the operation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-operation4.png"></div>
 <p>

 </p>
 <p>The content of an Operation may comprise
 						<a class="link" href="#OCLstdlib-Pre" title="Pre">Preconditions</a>,
 						<a class="link" href="#OCLstdlib-Post" title="Post">Postconditions</a> and Annotations.
 					</p>
 <p>The
 						<code class="code">static</code> qualifier supports declaration of static library operations such as
 						<code class="code">allInstances()</code> that are invoked on types rather than objects.
 					</p>
 </div>
 <div class="section" title="LibIteration">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-LibIteration"></a>LibIteration</h4>
 </div>
 </div>
 </div>
 <p>The LibIteration syntax defines an Iteration.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-iteration1.png"></div>
 <p>

 </p>
 <p>An Iteration has a name and optionally template parameters.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-iteration2.png"></div>
 <p>

 </p>
 <p>An Iteration has one or more comma-separated
 						<a class="link" href="#OCLstdlib-Iterator" title="Iterator">Iterators</a>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-iteration3.png"></div>
 <p>

 </p>
 <p>Optionally following a semicolon, an Iteration has one or more comma-separated
 						<a class="link" href="#OCLstdlib-Accumulator" title="Accumulator">Accumulators</a>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-iteration4.png"></div>
 <p>

 </p>
 <p>Optionally following a bar, an Iteration has one or more comma-separated
 						<a class="link" href="#OCLstdlib-Parameter" title="Parameter">Parameters</a>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-iteration5.png"></div>
 <p>

 </p>
 <p>An Iteration has a return Type. An Iteration may specify the name of a Java class implementing the org.eclipse.ocl.library.LibraryIteration interface. This class is used when evaluating the iteration.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-iteration6.png"></div>
 <p>

 </p>
 <p>The content of an Iteration may comprise
 						<a class="link" href="#OCLstdlib-Pre" title="Pre">Preconditions</a>,
 						<a class="link" href="#OCLstdlib-Post" title="Post">Postconditions</a> and Annotations.
 					</p>
 </div>
 <div class="section" title="Iterator">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Iterator"></a>Iterator</h4>
 </div>
 </div>
 </div>
 <p>The Iterator syntax defines an Iterator.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-iterator.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Accumulator">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Accumulator"></a>Accumulator</h4>
 </div>
 </div>
 </div>
 <p>The Accumulator syntax defines an Accumulator.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-accumulator.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Parameter">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Parameter"></a>Parameter</h4>
 </div>
 </div>
 </div>
 <p>The Parameter syntax defines a Parameter.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-parameter.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Pre">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Pre"></a>Pre</h4>
 </div>
 </div>
 </div>
 <p>The Pre syntax defines a precondition constraint.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-pre.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Post">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Post"></a>Post</h4>
 </div>
 </div>
 </div>
 <p>The Post syntax defines a postcondition constraint.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-post.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="LibProperty">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Property"></a>LibProperty</h4>
 </div>
 </div>
 </div>
 <p>The LibProperty syntax defines an Property.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-property1.png"></div>
 <p>

 </p>
 <p>An Property may be static and has a name and a Type.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-property2.png"></div>
 <p>

 </p>
 <p>A Property may specify the name of a Java class implementing the org.eclipse.ocl.library.LibraryProperty interface. This class is used when evaluating the iteration.</p>
 <p>The content of a Property may comprise Annotations.</p>
 </div>
 <div class="section" title="Specification">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLstdlib-Specification"></a>Specification</h4>
 </div>
 </div>
 </div>
 <p>The Specification syntax integrates an OCL Expression as the specification of a constraint.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1400-specification.png"></div>
 <p>

 </p>
 </div>
 </div>
 </div>
 <div class="section" title="Editors">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Editors"></a>Editors</h2>
 </div>
 </div>
 </div>
 <p>The four editors are all generated using
 				<a class="ulink" href="../../org.eclipse.xtext.doc/contents/xtext.html" target="_new">Xtext</a>, and so exhibit similar behavior to  other Eclipse editors.
 			</p>
 <p>The standard facilities are</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>syntax coloring</p>
 </li>
 <li class="listitem">
 <p>folding</p>
 </li>
 <li class="listitem">
 <p>outline view</p>
 </li>
 <li class="listitem">
 <p>hover text</p>
 </li>
 <li class="listitem">
 <p>syntax validation</p>
 </li>
 <li class="listitem">
 <p>semantic validation</p>
 </li>
 </ul>
 </div>
 <p>The following facilities have partial functionality</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>go to definition</p>
 </li>
 <li class="listitem">
 <p>content assist</p>
 </li>
 <li class="listitem">
 <p>templates</p>
 </li>
 <li class="listitem">
 <p>quick fixes</p>
 </li>
 <li class="listitem">
 <p>find references</p>
 </li>
 </ul>
 </div>
 <p>The following facilities have little or no functionality</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>rename element</p>
 </li>
 <li class="listitem">
 <p>final validation</p>
 </li>
 </ul>
 </div>
 <div class="section" title="Syntax coloring">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Syntaxcoloring"></a>Syntax coloring</h3>
 </div>
 </div>
 </div>
 <p>The editors use similar colors to JDT.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>green for comments</p>
 </li>
 <li class="listitem">
 <p>bold purple for keywords</p>
 </li>
 <li class="listitem">
 <p>grey for numbers</p>
 </li>
 <li class="listitem">
 <p>blue for strings</p>
 </li>
 </ul>
 </div>
 <p>Additionally</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>italics for text referencing a definition</p>
 </li>
 </ul>
 </div>
 <p>References for which the name of the definition matches a keyword use italics in the same way as other cross references. Names of a definition matching a keyword use bold purple in the same way as keywords.</p>
 <p>The syntax coloring may be changed using the
 					<span class="bold"><strong>Window-&gt;Preferences-&gt;OCL</strong></span> pages.
 				</p>
 </div>
 <div class="section" title="Validation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Validation"></a>Validation</h3>
 </div>
 </div>
 </div>
 <p>Syntax errors are detected and offending text is underlined with accompanying annotations and problem markers.</p>
 <p>If there are no syntax errors, semantic validation is performed with similar feedback of problems. Semantic validation is not performed when there are syntax errors since a single syntax error may provoke many hundreds of semantic errors. These can make the original syntax error difficult to resolve.</p>
 <p>The use of the well-formedness rules for a final validation of the Abstract Syntax is only partially implemented,
 					since correction of the OCL in the OMG specifiucation is still work in progress.</p>
 <p>By default, the Xtext nature is not added to projects using OCL editors and so no builder runs in the background creating problem markers for OCL files. This is generally beneficial when you have many files for which the over-enthusiastic rebuilds waste build time, or experimental files for which the many errors clutter the Problem View. </p>
 <p>If your OCL is good quality, you may activate the Xtext nature and builder by selecting the project and then invoking
 					<span class="bold"><strong>Configure-&gt;Add Xtext Nature</strong></span>.
 				</p>
 </div>
 <div class="section" title="Hover Text">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="HoverText"></a>Hover Text</h3>
 </div>
 </div>
 </div>
 <p>Hover text has been implemented to provide feedback on the usage and type of expression terms. For instance hovering over the size operation in the example below reveals that it is an Operation for the Loan specialization of Collection . </p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1510-hovertext.png"></div>
 <p>

 </p>
 <p>(Note that the Class specialization for Loan is incorrectly shown again as an Operation specialization.)</p>
 </div>
 <div class="section" title="Content Assist">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ContentAssist"></a>Content Assist</h3>
 </div>
 </div>
 </div>
 <p>Typing
 					<span class="bold"><strong>Ctrl</strong></span> and
 					<span class="bold"><strong>Space</strong></span> activates the Content Assist pop-up to offer suggestions as to what might be typed to the right of the cursor.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1510-contentassist.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Code Templates">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CodeTemplates"></a>Code Templates</h3>
 </div>
 </div>
 </div>
 <p>Code templates are provided for many of the major constructs and some expression elements.</p>
 <p>You may define your own templates. If you would like to contribute them, please raise a Bugzilla.</p>
 </div>
 <div class="section" title="Open Declaration">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OpenDeclaration"></a>Open Declaration</h3>
 </div>
 </div>
 </div>
 <p>It is possible to navigate to a definition provided an editor is already open for the definition. </p>
 </div>
 </div>
 <div class="section" title="OCL Nature and Builder Auto-Validation">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="NatureAndBuilder"></a>OCL Nature and Builder Auto-Validation</h2>
 </div>
 </div>
 </div>
 <p>The build of an OCL or OCL-containing source file validates the ource file and updates markers in the Problems View to identify issues that the user may care to address. Double-clicking on the Problems View Marker opens an
 				editor to faciltate fixing the problem.</p>
 <p>The build validation occurs whenever a source file changes or is &lsquo;cleaned&rsquo; and when the containing project
 				has the OCL nature configured.</p>
 <p>If the Eclipse Workspace is configured to auto-build, the OCL builder runs automatically and so auto-validation occurs.</p>
 <div class="section" title="Configuring the OCL Nature and Builder">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLbuilderConfiguration"></a>Configuring the OCL Nature and Builder</h3>
 </div>
 </div>
 </div>
 <p>The OCL Nature may be added or removed from a Project by selecting the project in an Explorer View and
 					invoking
 					<span class="bold"><strong>Configure-&gt;Convert to OCL Project</strong></span> or
 					<span class="bold"><strong>Configure-&gt;Unconfigure OCL</strong></span> from the context menu. Alternatively
 					the new Project Natures page may be used from the Project Properties page.
 				</p>
 <p>Configuing the OCL nature modifies the
 					<span class="bold"><strong>.project</strong></span> file to add the
 					<span class="bold"><strong>org.eclipse.ocl.pivot.ui.oclnature</strong></span> nature
 					and
 					<span class="bold"><strong>org.eclipse.ocl.pivot.ui.oclbuilder</strong></span>. The builder has an argument dictionaries to select file extensions
 					and file paths that are included or excluded by the builder.
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">&lt;arguments&gt;<br>
 	&lt;dictionary&gt;<br>
 		&lt;key&gt;disabledExtensions&lt;/key&gt;<br>
 		&lt;value&gt;*,essentialocl&lt;/value&gt;<br>
 	&lt;/dictionary&gt;<br>
 	&lt;dictionary&gt;<br>
 		&lt;key&gt;disabledPaths&lt;/key&gt;<br>
 		&lt;value&gt;bin/**,target/**&lt;/value&gt;<br>
 	&lt;/dictionary&gt;<br>
 	&lt;dictionary&gt;<br>
 		&lt;key&gt;enabledExtensions&lt;/key&gt;<br>
 		&lt;value&gt;ecore,ocl,oclinecore,oclstdlib,uml&lt;/value&gt;<br>
 	&lt;/dictionary&gt;<br>
 	&lt;dictionary&gt;<br>
 		&lt;key&gt;enabledPaths&lt;/key&gt;<br>
 		&lt;value&gt;**&lt;/value&gt;<br>
 	&lt;/dictionary&gt;<br>
 &lt;/arguments&gt;<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The default configuration enables validation of
 					<span class="bold"><strong>ecore,ocl,oclinecore,oclstdlib,uml</strong></span> extensions and disables all other extensions, redundantly adding an explicit
 					<span class="bold"><strong>essentialocl</strong></span> exclusion to make the syntax more obvious to a
 					casual reader. (*.essentialocl files may contain a single OCL expression, but since they lack any embedding within a model, they are not generally useful.)
 				</p>
 <p>The default configuration enables all paths except the
 					<span class="bold"><strong>bin</strong></span> and
 					<span class="bold"><strong>target</strong></span> paths where the Java builder or Maven builders may place copies of files that are not usually worth revalidating as distinct files.
 				</p>
 <p>The configuration in the
 					<span class="bold"><strong>.project</strong></span> file may be edited with a text editor; there is currently no dedicated user interface.
 				</p>
 </div>
 <div class="section" title="Ecore and UML Auto-Validation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="EcoreAndUMLautoValidation"></a>Ecore and UML Auto-Validation</h3>
 </div>
 </div>
 </div>
 <p>The EMF and UML projects provide no nature or builder and so Problems View markers for *.ecore and *.uml files
 					are dependent on the problems in the prevailing selection at the time of the preceding manual validation.</p>
 <p>Since OCL may be embedded with *.ecore or *.uml files, the OCL nature and builder provide the option to auto-validate these files.</p>
 <p>By default, your project has no OCL nature so no Ecore or UML auto-validation occurs.</p>
 <p>If you choose to add the OCL nature, the default settings that enable *.ecore and *.uml auto-validation apply. The Problems View markers resulting from auto-validation are updated after a file is saved; any markers that the Ecore or UML editors created are replaced.</p>
 <p>If you find that the auto-validation of some *.ecore and *.uml causes problems, perhaps because the reported
 					errors are not a concern for your usage, you may edit the
 					<span class="bold"><strong>.project</strong></span> file configuration.
 				</p>
 <p>You may remove
 					<span class="bold"><strong>ecore</strong></span> and/or
 					<span class="bold"><strong>uml</strong></span> from the
 					<span class="bold"><strong>enabledExtensions</strong></span> to suppress Ecore and/or UML auto-validation completely.
 				</p>
 <p>You may add individual files or file patterns to the
 					<span class="bold"><strong>disabledPaths</strong></span> to be more selective about disabling
 					auto-validation.
 				</p>
 </div>
 <div class="section" title="Building on pre-Photon / 2018 releases">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="NoNature"></a>Building on pre-Photon / 2018 releases</h3>
 </div>
 </div>
 </div>
 <p>The OCL builder and nature are new in the Eclipse OCL 2018 release (Photon). They comply with the standard Eclipse idiom.</p>
 <p>In earlier releases, the EMF idiom was followed whereby Problems View markers were created by their save action
 					of an appropriate editor. Problems in files that had not been saved were often not visible and so diagnosis
 					only occurred when some consuming application complained..</p>
 </div>
 </div>
 <div class="section" title="Console">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="InteractiveOCL"></a>Console</h2>
 </div>
 </div>
 </div>
 <p>There are two interactive OCL consoles that enable OCL expressions to be evaluated on a model.</p>
 <p>The classic
 				<span class="bold"><strong>Interactive Console</strong></span> may be created by invoking
 				<span class="bold"><strong>OCL-&gt;Show OCL Console</strong></span> from the right button menu of some model editors such as the
 				<span class="bold"><strong>Sample Ecore Model Editor</strong></span>. Alternatively the
 				<span class="bold"><strong>Console</strong></span> view may be created by
 				<span class="bold"><strong>Window-&gt;Show View-&gt;Console</strong></span> followed by selecting
 				<span class="bold"><strong>Interactive OCL</strong></span> from the
 				<span class="bold"><strong>Open Console</strong></span> pull-down in the
 				<span class="bold"><strong>Console</strong></span> View tool bar. See the
 				<a class="link" href="#OCLinEcoreTutorial-Console" title="The OCL Console">OCLinEcore Tutorial</a> for detailed step-by-step pictures.
 			</p>
 <p>The Pivot
 				<span class="bold"><strong>Interactive Xtext Console</strong></span> may be similarly created by
 				<span class="bold"><strong>OCL-&gt;Show Xtext OCL Console</strong></span> from the menu or
 				<span class="bold"><strong>Interactive Xtext OCL</strong></span> from the pull-down.
 			</p>
 <p>The two consoles should exhibit similar behaviors, however not all facilities of the classic console have yet been reproduced on the new.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1520-console.png"></div>
 <p>

 </p>
 <p>The Console, shown in the bottom half of the figure, comprises a combined Title and Tool Bar, Results Panel and Entry Panel.</p>
 <div class="section" title="Context Object Selection">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ContextObjectSelection"></a>Context Object Selection</h3>
 </div>
 </div>
 </div>
 <p>Expressions are evaluated with respect to a context object
 					<code class="code">self</code> that has a corresponding metamodel type. This object is defined by selecting any widget whose implementation is adaptable to an EObject. Therefore selecting an EAttribute in the Sample Ecore Editor will make the selected EAttribute
 					<code class="code">self</code> and EAttribute the metamodel type. In the figure selecting the Member named m1 in the Sample Reflective Ecore Model Editor has made Member the select type of
 					<code class="code">self</code> and m1 the selected context object. For the Pivot Console there is additional support to use selections from the Outline of an Xtext editor or Variables View of the OCL Debugger as the context object.
 				</p>
 <p>The Pivot Console displays the selected object and type in the Console title.</p>
 <p>The classic Console relies on the platform selection mechanism to show the selected object in the overall Eclipse Status display at the bottom left of the workspace window. This display may be lost when the selection is changed to a non-EObject selection.</p>
 </div>
 <div class="section" title="Editing">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Editing2"></a>Editing</h3>
 </div>
 </div>
 </div>
 <p>The bottom panel supports entry and evaluation of a multi-line expression. The expression is evaluated when
 					<span class="bold"><strong>Enter</strong></span> is entered.
 				</p>
 <p>The classic Console has hand-coded syntax highlighting and context assist that may be activated by typing
 					<span class="bold"><strong>Ctrl</strong></span> +
 					<span class="bold"><strong>Space</strong></span>.
 				</p>
 <p>The Pivot Console uses the Xtext EssentialOCL editor and largely auto-generated syntax highlighting, error indications, hover text, quick fixes and context assist that may be activated by typing
 					<span class="bold"><strong>Ctrl</strong></span> +
 					<span class="bold"><strong>Space</strong></span>.
 				</p>
 <p>The content assist for the Pivot Console has not yet been customized, so the classic Console content assist is probably more comprehensive, however the Pivot Console shares the same library definitions as the other editors and so is more consistent.</p>
 </div>
 <div class="section" title="Editor Keys">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="EditorKeys"></a>Editor Keys</h3>
 </div>
 </div>
 </div>
 <p>The
 					<span class="bold"><strong>Page-Up</strong></span> and
 					<span class="bold"><strong>Page-Down</strong></span> keys may be used to scroll through the history of input commands enabling previous commands to be re-used. Use of the Page keys is necessary since the input is potentially multi-line and so
 					<span class="bold"><strong>Up</strong></span> and
 					<span class="bold"><strong>Down</strong></span> navigate over the multiple lines.
 				</p>
 </div>
 <div class="section" title="Results">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Results"></a>Results</h3>
 </div>
 </div>
 </div>
 <p>The larger middle panel displays the results of each evaluation in a scrolling window.</p>
 </div>
 <div class="section" title="Tool Bar">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ToolBar"></a>Tool Bar</h3>
 </div>
 </div>
 </div>
 <div class="section" title="Ecore/UML binding">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="EcoreUMLbinding"></a>Ecore/UML binding</h4>
 </div>
 </div>
 </div>
 <p>The classic Console provides a selection to determine whether the context object has a type defined by an Ecore or UML metamodel. This selection is not required for the Pivot Console which automatically converts Ecore or UML models to Pivot models.</p>
 </div>
 <div class="section" title="M1/M2">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="M1M2"></a>M1/M2</h4>
 </div>
 </div>
 </div>
 <p>The classic Console provides a selection to determine whether the selected metamodel binding is that for objects (M2) or types (M1). This selection is not needed for the Pivot Console since the Pivot metamodel is an instance of itself.</p>
 </div>
 <div class="section" title="Clear Console">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ClearConsole"></a>Clear Console</h4>
 </div>
 </div>
 </div>
 <p>The standard clear console functionality clears the results pane.</p>
 </div>
 <div class="section" title="Close Console">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CloseConsole"></a>Close Console</h4>
 </div>
 </div>
 </div>
 <p>The standard close console functionality closes the current console.</p>
 </div>
 <div class="section" title="Debug">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Debug"></a>Debug</h4>
 </div>
 </div>
 </div>
 <p>Starts the
 						<a class="link" href="#Debugger" title="Debugger (new in Luna)">OCL Debugger</a> using the current mouse selection as self and the text in the Console input as the exopression to execute.
 					</p>
 </div>
 <div class="section" title="Load/Save an expression">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="LoadSaveanexpression"></a>Load/Save an expression</h4>
 </div>
 </div>
 </div>
 <p>The classic Console provides an ability to save and reload edited expressions as XMI files. The XMI is a pragmatic Eclipse Ecore realisation of the OCL specification for which XMI interchange is not realisable.</p>
 <p>The Pivot Console provides a similar ability to save and reload edited expressions as XMI files. The XMI is a prototype that might evolve and be adopted by a future version of the OCL specification.
 						<span class="italic">This functionality has not been properly tested.</span>

 </p>
 </div>
 </div>
 </div>
 <div class="section" title="Validity View (new in Luna)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="ValidityView"></a>Validity View (new in Luna)</h2>
 </div>
 </div>
 </div>
 <p>The standard EMF validation capabilities provide a useful overview of problems:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>as markers in the source model,</p>
 </li>
 <li class="listitem">
 <p>as markers in the Problems View,</p>
 </li>
 <li class="listitem">
 <p>in Pop-up dialogs.</p>
 </li>
 </ul>
 </div>
 <p>The
 				<span class="bold"><strong>Validity View</strong></span> provides a much more detailed view of the problems and so assists in debugging bad models and/or bad constaints.
 			</p>
 <p>The
 				<span class="bold"><strong>Validity View</strong></span> may be shown by invoking
 				<span class="bold"><strong>OCL-&gt;Show Validity View</strong></span> from the right button menu of some model editors such as the
 				<span class="bold"><strong>Sample Ecore Model Editor</strong></span>. Alternatively the
 				<span class="bold"><strong>Validity View</strong></span> view may be created by
 				<span class="bold"><strong>Window-&gt;Show View-&gt;Other... OCL-&gt;Validity View</strong></span>.
 			</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1530-validity-view.png"></div>
 <p>

 </p>
 <p>The left-hand pane titled Model Elements provides a tree view of the Resources in a ResourceSet in a similar fashion to the Sample Ecore Editor. However an additional child element (in blue italics) is added for each constraint applicable to its parent element. Checkboxes enable or disable the element from re-validations and JUnit-like status icons show the status of the most recent validation. Hovertext provides further detail.</p>
 <p>The right-hand pane titled Metamodel Constraints provides a tree view of the model hierarchies that contribute constraints. An additional child element is added for each model element to which the constraint applies.</p>
 <p>The displays track the mouse selection in other views. Whenever the mouse selection can be resolved to an EObject, that EObject&rsquo;s ResourceSet populates the left hand pane and constraints affecting the left hand pane populate the right hand pane. Tracking the mouse selection is quite expensive, and probably irritating. It can be inhibited by pinning the view to the current selection.</p>
 <p>There is generally much too much detail if all elements and constraints are considered and so the view provides many facilities to facilitate focusing on the interesting combinations.</p>
 <div class="section" title="View Tool Bar">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ValidityViewToolBar"></a>View Tool Bar</h3>
 </div>
 </div>
 </div>
 <p>The View Tool Bar is at the top and right of the view following the Validity View title. It provides facilities common to both Model Elements and Metamodel Constraints.</p>
 <div class="section" title="Expand All">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ExpandAll"></a>Expand All</h4>
 </div>
 </div>
 </div>
 <p>The plus icon causes the Model Elements and Metamodel Constraints to be fully expanded to display all their contents. Beware that for large models this may result in slow screen updates. </p>
 </div>
 <div class="section" title="Collapse All">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CollapseAll"></a>Collapse All</h4>
 </div>
 </div>
 </div>
 <p>The minus icon causes the Model Elements and Metamodel Constraints to collapse to display only their top level elements. </p>
 </div>
 <div class="section" title="Pin">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Pin"></a>Pin</h4>
 </div>
 </div>
 </div>
 <p>The pin icon toggles the track current cursor selection. When unpinned, the default, any change in mouse selection may cause recomputation of Model Elements and Metamodel Constraints contents. When pinned the contents are stable.</p>
 </div>
 <div class="section" title="Refresh">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Refresh"></a>Refresh</h4>
 </div>
 </div>
 </div>
 <p>The double arrow icon causes the Model Elements and Metamodel Constraints to be recomputed. This may be necessary for a metamodel change to be used.</p>
 </div>
 <div class="section" title="Run">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Run"></a>Run</h4>
 </div>
 </div>
 </div>
 <p>The white triangle in green circle icon runs a validation on all enabled model element/constraint combinations updating the status indications for constraints in the left hand Model Element and model elements in right hand Constraint pane.</p>
 </div>
 <div class="section" title="Filter">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Filter"></a>Filter</h4>
 </div>
 </div>
 </div>
 <p>The Filtering menu hides unwanted contributions to the display. Each of the validation result statuses can be individually enabled.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Show all errors</p>
 </li>
 <li class="listitem">
 <p>Show all infos</p>
 </li>
 <li class="listitem">
 <p>Show all failures</p>
 </li>
 <li class="listitem">
 <p>Show all warnings</p>
 </li>
 <li class="listitem">
 <p>Show all successes</p>
 </li>
 </ul>
 </div>
 <p>By default none of the selections are enabled so everything is shown. As soon as a specific status is enabled all display elements with other non-enabled statuses are hidden. Thus selecting just *Show all warnings" hides error/info/failure/success results.</p>
 </div>
 <div class="section" title="Save">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Save"></a>Save</h4>
 </div>
 </div>
 </div>
 <p>The floppy disk icon supports export of the validation results.</p>
 <p>The available export formats are extensible through the org.eclipse.ocl.examples.emf.validation.validity.validity_exporter extension point.</p>
 <p>The default exporters support</p>
 <div class="section" title="html">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="html"></a>html</h5>
 </div>
 </div>
 </div>
 <p>An HTML file summarising the results.</p>
 </div>
 <div class="section" title="model">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="model"></a>model</h5>
 </div>
 </div>
 </div>
 <p>An XMI model conforming to validity.ecore containing all results with references to the model elements and constraints.</p>
 </div>
 <div class="section" title="text">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="text"></a>text</h5>
 </div>
 </div>
 </div>
 <p>A text file summarising the results.</p>
 </div>
 </div>
 </div>
 <div class="section" title="Model Elements Pane">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ValidityViewModelElementsPane"></a>Model Elements Pane</h3>
 </div>
 </div>
 </div>
 <p>The Model Elements Pane is the left hand pane of the Validity View. </p>
 <p>It comprises a title and tool bar, text filter and scrollable tree of model elements and their constraints.</p>
 <div class="section" title="Model Elements Tool Bar">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ValidityViewModelElementsToolBar"></a>Model Elements Tool Bar</h4>
 </div>
 </div>
 </div>
 <p>The Model Elements Tool Bar is at the top and right of the left hand pane following the Model Elements title. It provides facilities specific to the Model Elements.</p>
 <div class="section" title="Expand All">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="ExpandAll2"></a>Expand All</h5>
 </div>
 </div>
 </div>
 <p>The plus icon causes the Model Elements to be fully expanded to display all their contents. Beware that for large models this may result in slow screen updates. </p>
 </div>
 <div class="section" title="Collapse All">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="CollapseAll2"></a>Collapse All</h5>
 </div>
 </div>
 </div>
 <p>The minus icon causes the Model Elements to collapse to display only their top level elements. </p>
 </div>
 <div class="section" title="Enable All">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="EnableAll"></a>Enable All</h5>
 </div>
 </div>
 </div>
 <p>The tick icon causes all Model Elements to be enabled and so included in the next validation.</p>
 </div>
 <div class="section" title="Disable All">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="DisableAll"></a>Disable All</h5>
 </div>
 </div>
 </div>
 <p>The no-tick icon causes all Model Elements to be disabled and so excluded from the next validation.</p>
 </div>
 <div class="section" title="Show/Hide disabled">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="ShowHidedisabled"></a>Show/Hide disabled </h5>
 </div>
 </div>
 </div>
 <p>The document icon with a query controls whether disabled Model Element selections are visible. A diagonal strikethrough shows when selections are hidden.</p>
 <p>By default disabled selections are hidden, which allows the unwanted root elements of large models to be unchecked and so hidden before a slow attempt is made to display them.</p>
 </div>
 </div>
 <div class="section" title="Text Filter">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="TextFilter"></a>Text Filter</h4>
 </div>
 </div>
 </div>
 <p>The text filter takes a StringMatcher pattern that selects which elements are visible. The pattern may contain</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>a * to match zero or more characters</p>
 </li>
 <li class="listitem">
 <p>a ? to match exactly one character</p>
 </li>
 <li class="listitem">
 <p>a \ to escape the following character</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Model Elements tree">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ModelElementstree"></a>Model Elements tree</h4>
 </div>
 </div>
 </div>
 <p>The scrollable tree shows the containment hierarchy of all elements in the ResourceSet containing the model element identified by the mouse selection.</p>
 <p>The +/- collapse/expand icons preceding each element enable interesting elements to be shown and others folded away.</p>
 <p>Each element is preceded by a check box that enables its usage within the next validation run. All elements may be enabled or disabled using the icons in the Model Elements Tool Bar. Enabling/disabling individual elements enables/disables the element&rsquo;s descendants and propagates a partial enable/disable to the element&rsquo;s ancestors.</p>
 <p>The checkbox is followed by a validation status icon.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>tick for validation successful</p>
 </li>
 <li class="listitem">
 <p>red cross for validation unsuccessful but incomplete</p>
 </li>
 <li class="listitem">
 <p>blue cross for validation failure (incomplete)</p>
 </li>
 <li class="listitem">
 <p>amber warning for a validation warning</p>
 </li>
 <li class="listitem">
 <p>question mark for no validation performed</p>
 </li>
 </ul>
 </div>
 <p>The status icon is followed by an element-specific icon identifying its type and label.</p>
 <p>Double-clicking a leaf Constraint in the left-hand pane makes the corresponding constraint and parent model-element visible in the right-hand pane.</p>
 </div>
 <div class="section" title="Model Elements Context Menu">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ModelElementsContextMenu"></a>Model Elements Context Menu</h4>
 </div>
 </div>
 </div>
 <p>The context menu in the model elements tree offers the following facilities in addition to those also available in the toolbar.</p>
 <div class="section" title="Validate Selection">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="ValidateSelection"></a>Validate Selection</h5>
 </div>
 </div>
 </div>
 <p>Revalidates all constraints applicable to the selected Model Element and its children.</p>
 </div>
 <div class="section" title="Debug Single Enabled Selection">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="DebugSingleEnabledSelection"></a>Debug Single Enabled Selection</h5>
 </div>
 </div>
 </div>
 <p>Launches the debugger for the selected Model Element and associated Constraint.</p>
 <p>The entry is greyed out if more than one Constraint is selected, so the invocation should normally be made from a leaf Constraint result.</p>
 <p>

 <span class="italic">Debug launching is only available for OCL constraints in Luna SR0.</span>

 </p>
 </div>
 <div class="section" title="Show in Editor">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="ShowinEditor"></a>Show in Editor</h5>
 </div>
 </div>
 </div>
 <p>Opens an editor for the selected Model Element or Metamodel Constraint.</p>
 <p>

 <span class="italic">Opening is not available for all forms of constraint in Luna SR0.</span>

 </p>
 </div>
 </div>
 </div>
 <div class="section" title="Metamodel Constraints Pane">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ValidityViewMetamodelConstraintsPane"></a>Metamodel Constraints Pane</h3>
 </div>
 </div>
 </div>
 <p>The Metamodel Constraints Pane is the right hand pane of the Validity View. </p>
 <p>It comprises a title and tool bar, text filter and scrollable tree of metamodel constraints and the model elements to which they apply.</p>
 <div class="section" title="Metamodel Constraints Tool Bar">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ValidityViewMetamodelConstraintsToolBar"></a>Metamodel Constraints Tool Bar</h4>
 </div>
 </div>
 </div>
 <p>The Metamodel Constraints Tool Bar is at the top and right of the right hand pane following the Metamodel Constraints title. It provides facilities specific to the Metamodel Constraints.</p>
 <div class="section" title="Expand All">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="ExpandAll3"></a>Expand All</h5>
 </div>
 </div>
 </div>
 <p>The plus icon causes the Metamodel Constraints to be fully expanded to display all their contents. Beware that for large models this may result in slow screen updates. </p>
 </div>
 <div class="section" title="Collapse All">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="CollapseAll3"></a>Collapse All</h5>
 </div>
 </div>
 </div>
 <p>The minus icon causes the Metamodel Constraints to collapse to display only their top level elements. </p>
 </div>
 <div class="section" title="Enable All">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="EnableAll2"></a>Enable All</h5>
 </div>
 </div>
 </div>
 <p>The tick icon causes all Metamodel Constraints to be enabled and so included in the next validation.</p>
 </div>
 <div class="section" title="Disable All">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="DisableAll2"></a>Disable All</h5>
 </div>
 </div>
 </div>
 <p>The no-tick icon causes all Metamodel Constraints to be disabled and so excluded from the next validation.</p>
 </div>
 <div class="section" title="Show/Hide disabled">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="ShowHidedisabled2"></a>Show/Hide disabled </h5>
 </div>
 </div>
 </div>
 <p>The document icon with a query controls whether disabled Metamodel Constraints selections are visible. A diagonal strikethrough shows when selections are hidden.</p>
 <p>By default disabled selections are hidden, which allows the unwanted root elements of large metamodels to be unchecked and so hidden before a slow attempt is made to display them. </p>
 </div>
 </div>
 <div class="section" title="Text Filter">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="TextFilter2"></a>Text Filter</h4>
 </div>
 </div>
 </div>
 <p>The text filter takes a StringMatcher pattern that selects which elements are visible. The pattern may contain</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>a * to match zero or more characters</p>
 </li>
 <li class="listitem">
 <p>a ? to match exactly one character</p>
 </li>
 <li class="listitem">
 <p>a \ to escape the following character</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Metamodel Constraints tree">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="MetamodelConstraintstree"></a>Metamodel Constraints tree</h4>
 </div>
 </div>
 </div>
 <p>The scrollable tree shows the containment hierarchy of all constraints applicable to model elements in the ResourceSet containing the model element identified by the mouse selection.</p>
 <p>The +/- collapse/expand icons preceding each element enable interesting elements to be shown and others folded away.</p>
 <p>Each element is preceded by a check box that enables its usage within the next validation run. All elements may be enabled or disabled using the icons in the Model Elements Tool Bar. Enabling/disabling individual elements enables/disables the element&rsquo;s descendants and propagates a partial enable/disable to the element&rsquo;s ancestors.</p>
 <p>The checkbox is followed by a validation status icon.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>tick for validation successful</p>
 </li>
 <li class="listitem">
 <p>red cross for validation unsuccessful but incomplete</p>
 </li>
 <li class="listitem">
 <p>blue cross for validation failure (incomplete)</p>
 </li>
 <li class="listitem">
 <p>amber warning for a validation warning</p>
 </li>
 <li class="listitem">
 <p>question mark for no validation performed</p>
 </li>
 </ul>
 </div>
 <p>The status icon is followed by an element-specific icon identifying its type and label.</p>
 <p>Double-clicking a leaf Model Element in the right-hand pane makes the corresponding Model Element and parent Metamodel Constraint visible in the left-hand pane.</p>
 </div>
 <div class="section" title="Metamodel Constraints Context Menu">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="MetamodelConstraintsContextMenu"></a>Metamodel Constraints Context Menu</h4>
 </div>
 </div>
 </div>
 <p>The context menu in the metamodel constraints tree offers the following facilities in addition to those also available in the toolbar.</p>
 <div class="section" title="Validate Selection">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="ValidateSelection2"></a>Validate Selection</h5>
 </div>
 </div>
 </div>
 <p>Revalidates all model elements applicable to the selected constraint and its children.</p>
 </div>
 <div class="section" title="Debug Single Enabled Selection">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="DebugSingleEnabledSelection2"></a>Debug Single Enabled Selection</h5>
 </div>
 </div>
 </div>
 <p>Launches the debugger for the selected Model Element and associated Constraint.</p>
 <p>The entry is greyed out if more than one Constraint is selected, so the invocation should normally be made from a leaf Model Element result.</p>
 <p>

 <span class="italic">Debug launching is only available for OCL constraints in Luna SR0.</span>

 </p>
 </div>
 <div class="section" title="Show in Editor">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="ShowinEditor2"></a>Show in Editor</h5>
 </div>
 </div>
 </div>
 <p>Opens an editor for the selected Model Element or Metamodel Constraint.</p>
 <p>

 <span class="italic">Opening is not available for all forms of constraint in Luna SR0.</span>

 </p>
 </div>
 </div>
 </div>
 <div class="section" title="Constraint Locators">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ConstraintLocators"></a>Constraint Locators</h3>
 </div>
 </div>
 </div>
 <p>The constraints displayed in the right hand pane are located by constraint locators that are registered with the org.eclipse.ocl.examples.emf.validation.validity.constraint_locator extension point. A constraint locator implements org.eclipse.ocl.examples.emf.validation.validity.locator.ConstraintLocator or the org.eclipse.ocl.examples.emf.validation.validity.ui.locator.ConstraintUILocator to define location, presentation, execution and debug launching of a particular kind of constraint.</p>
 <p>Constraint locators are associated with metamodel namespaces which are determined by the nsURI of the EPackage that contains the EClass of a Model Element EObject. Constraint locators may be registered for a particular metamodel namespace or for no namespace. Those registered for no namespace are activated whenever a namespace is encountered for which no specific constraint locators are registered.</p>
 <p>The following Constraint Locators are available by default.</p>
 <div class="section" title="org.eclipse.ocl.examples.emf.validation.validity.locator.EClassConstraintLocator">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="org.eclipse.ocl.examples.emf.validation.validity.locator.EClassConstraintLocator"></a>org.eclipse.ocl.examples.emf.validation.validity.locator.EClassConstraintLocator</h4>
 </div>
 </div>
 </div>
 <p>This constraint locator supports discovery of constraints realized by invariant EOperations in the Java code generated by an EMF genmodel.</p>
 </div>
 <div class="section" title="org.eclipse.ocl.examples.emf.validation.validity.locator.EValidatorConstraintLocator">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="org.eclipse.ocl.examples.emf.validation.validity.locator.EValidatorConstraintLocator"></a>org.eclipse.ocl.examples.emf.validation.validity.locator.EValidatorConstraintLocator</h4>
 </div>
 </div>
 </div>
 <p>This constraint locator supports reflective discovery of validateXXXX methods in the Java code generated by an EMF genmodel using the EValidatorRegistry to identify the relevant Java code.</p>
 </div>
 <div class="section" title="org.eclipse.ocl.examples.validity.locator.DelegateUIConstraintLocator">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="org.eclipse.ocl.examples.validity.locator.DelegateUIConstraintLocator"></a>org.eclipse.ocl.examples.validity.locator.DelegateUIConstraintLocator</h4>
 </div>
 </div>
 </div>
 <p>This constraint locator supports OCL constraints represented as EAnnotations in Ecore metamodels.</p>
 </div>
 <div class="section" title="org.eclipse.ocl.examples.validity.locator.PivotUIConstraintLocator">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="org.eclipse.ocl.examples.validity.locator.PivotUIConstraintLocator"></a>org.eclipse.ocl.examples.validity.locator.PivotUIConstraintLocator</h4>
 </div>
 </div>
 </div>
 <p>This constraint locator supports discovery of org.eclipse.ocl.pivot.Constraint classes in Pivot metamodels.</p>
 </div>
 <div class="section" title="org.eclipse.ocl.examples.validity.locator.UMLUIConstraintLocator">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="org.eclipse.ocl.examples.validity.locator.UMLUIConstraintLocator"></a>org.eclipse.ocl.examples.validity.locator.UMLUIConstraintLocator</h4>
 </div>
 </div>
 </div>
 <p>This constraint locator supports discovery of org.eclipse.uml2.uml.Constraint classes in UML metamodels.</p>
 </div>
 </div>
 </div>
 <div class="section" title="Debugger (new in Luna)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Debugger"></a>Debugger (new in Luna)</h2>
 </div>
 </div>
 </div>
 <p>The OCL debugger supports debugging OCL constraints. It is a customization of the standard Eclipse debugger and so most of the facilities should be familiar to users of the Eclipse Java debugger.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1540-debugger-image.png"></div>
 <p>

 </p>
 <p>The screenshot shows</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Debug Stack Trace showing the context of nested evaluation environments </p>
 </li>
 <li class="listitem">
 <p>Variables View showing intermediate and local variables</p>
 </li>
 <li class="listitem">
 <p>Editor showing input and context after a couple of steps</p>
 </li>
 <li class="listitem">
 <p>Outline showing the Concrete Syntax Tree context</p>
 </li>
 </ul>
 </div>
 <p>

 <span class="italic">The OCL Debugger is very new, there are no doubt many opportunities for ergonomic improvements and bug fixes. Please raise a
 					<a class="ulink" href="http://bugs.eclipse.org/bugs/enter_bug.cgi?product=MDT.OCL" target="_new">Bugzilla</a> .
 				</span>

 </p>
 <div class="section" title="Launching">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Launching"></a>Launching</h3>
 </div>
 </div>
 </div>
 <p>Launching the debugger for an OCL constraint requires the user to provide two pieces of information</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>the expression or constraint to evaluate</p>
 </li>
 <li class="listitem">
 <p>the self object upon which to operate</p>
 </li>
 </ul>
 </div>
 <p>These may be provided in a variety of ways</p>
 <div class="section" title="Selected model object and manually entered expression">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Selectedmodelobjectandmanuallyenteredexpression"></a>Selected model object and manually entered expression</h4>
 </div>
 </div>
 </div>
 <p>An arbitrary OCL expression may be entered in the Xtext OCL Console and evaluated on a model object selected using a mouse selection. The Debugger is invoked from the debug icon on the Console Tool Bar.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1540-debugger-console-launch.png"></div>
 <p>

 </p>
 <p>Clicking the debug icon creates a dummy Complete OCL file and then launches the debugger. The expression is encapsulated as an oclDebugExpression operation extension to the type of the selected object. The file provides the source for source level debugging. The console may be re-used while debugging.</p>
 </div>
 <div class="section" title="Selected model object/constraint combination">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Selectedmodelobjectconstraintcombination"></a>Selected model object/constraint combination</h4>
 </div>
 </div>
 </div>
 <p>The Validity View provides fine-grained display of the evaluation of each constraint applicable to a model element and vice-versa. One of these model element/constraint combinations may be selected and the debugger launched using
 						<span class="bold"><strong>Debug Single Enabled Selection</strong></span> to investigate why validation is producing unexpected results.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1540-debugger-validity-view-launch.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Selected model object and selected constraint">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Selectedmodelobjectandselectedconstraint"></a>Selected model object and selected constraint</h4>
 </div>
 </div>
 </div>
 <p>An OCL Expression launch configuration may be created to select a model element and a constraint for execution or debugging.</p>
 <p>The launch configuration may be created using
 						<span class="bold"><strong>Run-&gt;Run Configurations...</strong></span> or
 						<span class="bold"><strong>Debug-&gt;Debug Configurations...</strong></span> from the Eclipse Menu Bar. This requires both Model Element and Constraint to be selected separately.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1540-debugger-run-configuration-launch.png"></div>
 <p>

 </p>
 <p>Alternatively the context menu in model editors offers an
 						<span class="bold"><strong>OCL-&gt;Debug...</strong></span> option that creates a Debug Configuration in which the Model Element is pre-selected from the invoking context.
 					</p>
 </div>
 </div>
 <div class="section" title="Stepping">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Stepping"></a>Stepping</h3>
 </div>
 </div>
 </div>
 <p>OCL expressions can be very compact and generally occur embedded in a larger application. The debugger is therefore optimized for this usage.</p>
 <p>Rather than the line-based stepping typical of the Java debugger, the OCL debugger supports term by term stepping, highlighting the next term to be evaluated and showing the intermediate results as $-prefixed names in the Variables View. </p>
 <p>The OCL debugger interpretation of the Step functionalities is adjusted to facilitate stepping to many points in a complex expression without needing to reformat the source with line breaks..</p>
 <p>The
 					<a class="link" href="#Debugger" title="Debugger (new in Luna)">Example Debugger View</a> shows the imminent execution of &ldquo;.size()&rdquo; after stepping into &ldquo;self&rdquo; and &ldquo;.name&rdquo;.
 				</p>
 <div class="section" title="Step Into">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="StepInto"></a>Step Into</h4>
 </div>
 </div>
 </div>
 <p>A single OCL AST node is executed. The results can be inspected as inputs of a subsequent AST node.</p>
 </div>
 <div class="section" title="Step Over">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="StepOver"></a>Step Over</h4>
 </div>
 </div>
 </div>
 <p>Execution proceeds until the next OCL AST node is associated with a new source line number.</p>
 </div>
 <div class="section" title="Step Return">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="StepReturn"></a>Step Return</h4>
 </div>
 </div>
 </div>
 <p>Execution proceeds until the next OCL AST node is associated with a reduced stack depth. Iterations introduce nested stack entries so step return can step out of an iteration. let expressions and nested OCL calls also introduce additional stack nesting.</p>
 </div>
 <div class="section" title="Resume">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Resume"></a>Resume</h4>
 </div>
 </div>
 </div>
 <p>Execution proceeds until the next breakpoint.</p>
 </div>
 </div>
 <div class="section" title="Variables View">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="VariablesView"></a>Variables View</h3>
 </div>
 </div>
 </div>
 <p>The Variables View enables the local variables and intermediate results to be examined using OCL syntaxes such as single quotes for Strings.</p>
 <p>The
 					<a class="link" href="#Debugger" title="Debugger (new in Luna)">Example Debugger View</a> shows the &ldquo;self&rdquo; variable, which is an &ldquo;ecore::Package&rdquo; instance, opened to show its fields, amongst which the name is &lsquo;tutorial&rsquo;.
 				</p>
 <p>Intermediate variables are named using the property name of the subsequent AST node&rsquo;s input. Thus &ldquo;$source&rdquo; shows the OperationCallExp.source input already computed as &ldquo;self.name&rdquo;. Multiple inputs are diasmbiguated by suffixing as in &ldquo;$argument[0]&rdquo;.</p>
 <p>&ldquo;$pc&rdquo; identifies the next instruction, which can be examined in just the same way as any other variable.</p>
 </div>
 <div class="section" title="Breakpoints View">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="BreakpointsView"></a>Breakpoints View</h3>
 </div>
 </div>
 </div>
 <p>Line breakpoints can be set in the Complete OCL editor and examined in the Breakpoints View. Execution stops when an OCL AST node has been executed that is associated with the line of a breakpoint.</p>
 <p>

 <span class="italic">No filtering facilities are yet available.</span>

 </p>
 </div>
 <div class="section" title="Outline View">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OutlineView"></a>Outline View</h3>
 </div>
 </div>
 </div>
 <p>The Outline currently shows the OCL Concrete Syntax Tree which is structurally similar to the Abstract Syntax Tree that is executed. .</p>
 <p>

 <span class="italic">It would be more useful to show the AST and support Node breakpoints on it.</span>

 </p>
 </div>
 </div>
 <div class="section" title="OCL Integration">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Integration"></a>OCL Integration</h2>
 </div>
 </div>
 </div>
 <p>The
 				<a class="link" href="#OCLinEcore" title="The OCLinEcore Language">OCLinEcore Editor</a> editor enables OCL to be embedded in Ecore. This section explains how that OCL is executed.
 			</p>
 <p>The
 				<a class="link" href="#CompleteOCL" title="The Complete OCL Language">Complete OCL</a> editor enables OCL to be provided as a complementing document. This section explains how that complement is installed to become part of the complemented model.
 			</p>
 <p>The
 				<a class="link" href="#InteractiveOCL" title="Console">Interactive OCL</a> console allows you to load OCL and execute OCL expression interactively.
 			</p>
 <p>The
 				<a class="link" href="#ProgrammersGuide" title="Chapter&nbsp;6.&nbsp;Classic Ecore/UML Programmers Guide">Java API</a> explains how you can take control of the OCL installation and activation.
 			</p>
 <div class="section" title="OCL execution in Ecore / EMF Delegates">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Integration-OCLinEcore"></a>OCL execution in Ecore / EMF Delegates</h3>
 </div>
 </div>
 </div>
 <p>The EMF delegate mechanisms and EAnnotations that enable EMF to delegate to OCL to support</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>validation of invariants</p>
 </li>
 <li class="listitem">
 <p>execution of operation bodies</p>
 </li>
 <li class="listitem">
 <p>evaluation of property initial and derived values</p>
 </li>
 </ul>
 </div>
 <p>are described in the
 					<a class="link" href="#Delegates" title="Delegates">Delegates</a> section of the Programmers Guide.
 				</p>
 </div>
 <div class="section" title="Custom Validation Messages">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Integration-Messages"></a>Custom Validation Messages</h3>
 </div>
 </div>
 </div>
 <p>Eclipse OCL supports the production of custom messages by defining a String-valued message expression as a parenthesized clause on an invariant.</p>
 <div class="section" title="Underlying support">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Underlyingsupport"></a>Underlying support</h4>
 </div>
 </div>
 </div>
 <p>An OCL invariant is an expression that returns a true or false value.</p>
 <p>In Juno and Kepler, Eclipse OCL supported an extension whereby a null return indicated an &lsquo;error&rsquo; rather than a &lsquo;warning&rsquo;, and an invalid return was &lsquo;fatal&rsquo;.</p>
 <p>Luna supports a rich-invariant idiom whereby an invariant can compute a tuple of results, only one of which is actually returned by tooling that does not understand the idiom. Rather than</p>
 <div class="literallayout">
 <p>
 <code class="code">invariant&nbsp;InvariantName:<br>
 	boolean-valued-invariant-expression;<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>You can code additional information by recoding</p>
 <p>ocl-status-expression</p>
 <p>as</p>
 <div class="literallayout">
 <p>
 <code class="code">invariant&nbsp;InvariantName:<br>
 	Tuple{<br>
 	&nbsp;&nbsp;&nbsp;&nbsp;status=boolean-valued-invariant-expression,<br>
 	&nbsp;&nbsp;&nbsp;&nbsp;message=string-valued-message-expression,<br>
 	&nbsp;&nbsp;&nbsp;&nbsp;severity=integer-valued-severity-expression,&nbsp;--&nbsp;-ve&nbsp;error,0&nbsp;ok,+ve&nbsp;warn<br>
 	&nbsp;&nbsp;&nbsp;&nbsp;...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--&nbsp;more&nbsp;custom&nbsp;fields&nbsp;as&nbsp;desired<br>
 	}.status;<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The idiom is a little verbose, but compatible with all OCL tooling. Eclipse OCL provides some editor enhancements to make the usage more acceptable.</p>
 </div>
 <div class="section" title="Editor syntax">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Editorsyntax"></a>Editor syntax</h4>
 </div>
 </div>
 </div>
 <p>In the OCLinEcoreTutorial Example there is an alternative syntax for custom messages.</p>
 <div class="literallayout">
 <p>
 <code class="code">invariant&nbsp;SufficientCopies:<br>
 	library.loans-&gt;select((book&nbsp;=&nbsp;self))-&gt;size()&nbsp;&lt;=&nbsp;copies;<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>may be changed to</p>
 <div class="literallayout">
 <p>
 <code class="code">invariant&nbsp;SufficientCopies('There&nbsp;are&nbsp;'<br>
 	+&nbsp;library.loans-&gt;select((book&nbsp;=&nbsp;self))-&gt;size().toString()<br>
 	+&nbsp;'&nbsp;loans&nbsp;for&nbsp;the&nbsp;'&nbsp;+&nbsp;copies.toString()&nbsp;+&nbsp;'&nbsp;copies&nbsp;of&nbsp;\''&nbsp;+&nbsp;name&nbsp;+&nbsp;'\''):<br>
 	library.loans-&gt;select((book&nbsp;=&nbsp;self))-&gt;size()&nbsp;&lt;=&nbsp;copies;<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>to replace the default diagnostic:</p>
 <div class="literallayout">
 <p>
 <code class="code">The&nbsp;'SufficientCopies'&nbsp;constraint&nbsp;is&nbsp;violated&nbsp;on&nbsp;'Book&nbsp;b2'.<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>by</p>
 <div class="literallayout">
 <p>
 <code class="code">There&nbsp;are&nbsp;3&nbsp;loans&nbsp;for&nbsp;the&nbsp;2&nbsp;copies&nbsp;of&nbsp;'b2'.<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>Unfortunately, in the Photon release, EMF does not support this customization. This must be activated explicitly using an EValidator that is aware of the ValidationDelegateExtension extended API. This is available by using the
 						<a class="link" href="#OCLinEcoreEObjectValidator" title="OCLinEcoreEObjectValidator">OCLinEcoreEObjectValidator</a>.
 					</p>
 </div>
 </div>
 <div class="section" title="CompleteOCL Validation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Integration-CompleteOCL"></a>CompleteOCL Validation</h3>
 </div>
 </div>
 </div>
 <p>Integration of Complete OCL documents is harder because Complete OCL complements pre-existing models. These cannot always be aware of the existence of that complement, since the author of a model cannot know what complements may be added by its users.</p>
 <p>The complete model formed from the primary models and the OCL complements is application-specific and so applications must gather the contributions together. Prior to the Indigo release, this restricted Complete OCL usage to Java applications that could gather the complements.</p>
 <p>The
 					<a class="link" href="#CompleteOCLEObjectValidator" title="CompleteOCLEObjectValidator">CompleteOCLEObjectValidator</a> may be used to install a Complete OCL document.
 				</p>
 <p>In many editors an
 					<span class="bold"><strong>OCL-&gt;Load Document</strong></span> is available in the context menu to facilitate loading a complementary Complete OCL document.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1600-load-document.png"></div>
 <p>

 </p>
 <p>You may drag and drop one or more files from within Eclipse or outside Eclipse into the dialog, or use one of the browser buttons to locate a Complete OCL document.</p>
 <div class="section" title="Browse Registered OCL Files...">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="BrowseRegisteredOCLFiles..."></a>Browse Registered OCL Files...</h4>
 </div>
 </div>
 </div>
 <p>The org.eclipse.ocl.xtext.completeocl.complete_ocl_registry may be used to register Complete OCL files against the nsURIs that they complement. These extension points may be defined in plugins or projects. In either case clicking
 						<span class="bold"><strong>Browse Registered OCL Files...</strong></span> presents a list of registered Complete OCL documents applicable to the context from which the dialog was invoked.
 					</p>
 </div>
 <div class="section" title="Browse File System...">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="BrowseFileSystem..."></a>Browse File System...</h4>
 </div>
 </div>
 </div>
 <p>The
 						<span class="bold"><strong>Browse File System...</strong></span> button present a file system explorer so that a Complete OCL document file can found anywhere.
 					</p>
 </div>
 <div class="section" title="Browse Workspace...">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="BrowseWorkspace..."></a>Browse Workspace...</h4>
 </div>
 </div>
 </div>
 <p>The
 						<span class="bold"><strong>Browse Workspace...</strong></span> button present a workspace explorer so that a Complete OCL document file can found within the workspace.
 					</p>
 </div>
 </div>
 <div class="section" title="OCLinEcore for Xtext Validation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLinEcoreforXtextValidation"></a>OCLinEcore for Xtext Validation</h3>
 </div>
 </div>
 </div>
 <p>If you want to use OCLinEcore as a validation language for Xtext you must:</p>
 <p>Use a manually maintained Ecore model to define your parsed grammar model, otherwise your embedded OCL will be lost each time you regenerate the editor. For non-trivial models, switching from auto-generated to manual maintenance is a good idea, since you may need to control changes carefully to maintain upward compatibility for existing models.</p>
 <p>Modify the Validator class generated by genmodel to extend OCLinEcoreEObjectValidator rather than EObjectValidator. See
 					<a class="link" href="#OCLinEcoreEObjectValidator" title="OCLinEcoreEObjectValidator">OCLinEcoreEObjectValidator</a> for details.
 				</p>
 </div>
 <div class="section" title="Complete OCL for Xtext Validation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CompleteOCLforXtextValidation"></a>Complete OCL for Xtext Validation</h3>
 </div>
 </div>
 </div>
 <p>If you want to use Complete OCL as a validation language for Xtext, you may use the
 					<a class="link" href="#CompleteOCLEObjectValidator" title="CompleteOCLEObjectValidator">CompleteOCLEObjectValidator</a> to register the Complete OCL for EMF Validation. This may readily be achieved by reusing the empty example JavaValidator created by Xtext to install the Complete OCL. If your Xtext language is
 					<span class="emphasis"><em>States</em></span>, and your Complete OCL is
 					<span class="emphasis"><em>model/States.ocl</em></span> in
 					<span class="emphasis"><em>StatesProject</em></span> you should change your StatesJavaValidator to:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">public&nbsp;class&nbsp;StatesJavaValidator&nbsp;extends&nbsp;AbstractStatesJavaValidator<br>
 {<br>
 &nbsp;&nbsp;&nbsp;&nbsp;@Override<br>
 &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;void&nbsp;register(EValidatorRegistrar&nbsp;registrar)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super.register(registrar);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StatesPackage&nbsp;ePackage&nbsp;=&nbsp;StatesPackage.eINSTANCE;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;URI&nbsp;oclURI&nbsp;=&nbsp;URI.createPlatformResourceURI(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"/StatesProject/model/States.ocl",&nbsp;true);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;registrar.register(ePackage,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;new&nbsp;CompleteOCLEObjectValidator(ePackage,&nbsp;oclURI));<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 </div>
 <div class="section" title="OCL in UML (using Papyrus)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OCLinPapyrus"></a>OCL in UML (using Papyrus)</h2>
 </div>
 </div>
 </div>
 <p>(This documentation applies to Papyrus 1.0.0.)</p>
 <p>The behaviour of a UML model may be elaborated using OCL to define</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>operation bodies</p>
 </li>
 <li class="listitem">
 <p>property derivations/initializers</p>
 </li>
 <li class="listitem">
 <p>class invariants to be observed by user model instances</p>
 </li>
 <li class="listitem">
 <p>stereotype invariants to be observed by user model elements</p>
 </li>
 <li class="listitem">
 <p>guards for state machines </p>
 </li>
 </ul>
 </div>
 <div class="section" title="UML Integration">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLinPapyrus-UML-integration"></a>UML Integration</h3>
 </div>
 </div>
 </div>
 <p>Although the UML metamodel makes extensive use of OCL to specify its own well-formedness, there is no explicit ability to use OCL within UML. Usage of OCL, or any other language, is enabled by the flexibility of the ValueSpecification class and the OpaqueExpression extension.</p>
 <p>The metamodel specifies the usage of a ValueSpecification wherever a value can sensibly be provided by a variety of technologies. Simple values can be provided by, for instance, a LiteralString or LiteralInteger. More interesting values
 					by an OpaqueExpression that has two interesting list features, one of language names and the other of string bodies in the corresponding language. The lists provide an ability to provide implementations in a variety of languages. In practice only
 					one is used and if the language name is omitted, an implementation default of OCL is assumed.</p>
 <p>Specification of a behaviour such as &ldquo;name.toUpper()&rdquo; can be achieved by an OpaqueExpression in which the language is Sequence(&lsquo;OCL&rsquo;) and the body is Sequence(&lsquo;name.toUpper()&rsquo;). The OCL is therefore embedded in a textual form that has no knowledge of the classes in the OCL metamodel.</p>
 <p>Users of the OCL Java API may avoid the need to incur OCL parsing costs by exploiting OCL&rsquo;s ExpressionInOCL class that extends ValueSpecification and delegates functionality to an OCLExpression.</p>
 </div>
 <div class="section" title="Class Diagram">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLinPapyrus-Class-Diagram"></a>Class Diagram</h3>
 </div>
 </div>
 </div>
 <div class="section" title="Class Invariant">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinPapyrus-Class-Invariant"></a>Class Invariant</h4>
 </div>
 </div>
 </div>
 <p>A class invariant specifies a constraint that must be true for all well-formed instances of the class. It is specified in Papyrus, by:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>create a Constraint Node on a Class Diagram</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select Constraint on palette</p>
 </li>
 <li class="listitem">
 <p>click on diagram where you want it</p>
 </li>
 <li class="listitem">
 <p>click on the Class you want as the Constraint context</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>optionally replace the auto-generated Constraint name</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select the Constraint</p>
 </li>
 <li class="listitem">
 <p>type a new name in the Properties View</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>define the Specification of the Constraint with OCL text</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select the Constraint</p>
 </li>
 <li class="listitem">
 <p>type F2 (or click again) to open the Essential OCL editor</p>
 </li>
 <li class="listitem">
 <p>enter the required constraint text</p>
 </li>
 <li class="listitem">
 <p>click outside the editor to close</p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1710-class-invariant.png"></div>
 <p>

 </p>
 <p>The &laquo;Context&raquo; link provides a graphical view of the Context selection in the Properties View. It is the context that defines the type of OCL&rsquo;s
 						<code class="code">self</code> and so defines what is constrained.
 					</p>
 <p>You may edit the OCL text using direct edit as described above or from The Properties View. (Note that the editor has a significant start up time on the first usage, so be patient).</p>
 <p>Your OCL text entry is validated automatically; an error or warning marker will be shown on the Constraint if it is not satisfactory. Once you have corrected the errors you may need to invoke
 						<span class="bold"><strong>Validate-&gt;Model Tree</strong></span> to make the marker go away.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1710-class-invariant-error.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Operation Precondition, Postcondition and Body">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinPapyrus-Operation-Constraints"></a>Operation Precondition, Postcondition and Body</h4>
 </div>
 </div>
 </div>
 <p>Preconditions specify constraints that must be satisfied before operation execution starts. </p>
 <p>Postconditions specify constraints that must be satisfied after operation execution finishes. Postconditions may use the reserved parameter name
 						<code class="code">result</code> to refer to the one result permitted by OCL. The @pre suffix may be used to refer to the state of variables prior to execution of the operation.
 					</p>
 <p>In OCL, a body-expression defines the functionality of a query operation as a result-type-valued expression such as
 						<code class="code">some-computation</code>. In contrast in UML, a body-condition defines the functionality of the operation as a Boolean-valued constraint on the result such as
 						<code class="code">result = (some-computation)</code>. Papyrus supports the OCL interpretation and so the
 						<code class="code">result = (...)</code> wrapper may be omitted.
 					</p>
 <p>In Papyrus, once the operation has been defined, preconditions, postconditions and a body-condition are all drawn by</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>create a Constraint Node on a Class Diagram</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select Constraint on palette</p>
 </li>
 <li class="listitem">
 <p>click on diagram where you want it</p>
 </li>
 <li class="listitem">
 <p>type Esc since context links cannot be drawn to operations</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>optionally replace the auto-generated Constraint name</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select the Constraint</p>
 </li>
 <li class="listitem">
 <p>type a new name in the Properties View</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>define the Constraint Context</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select the Operation</p>
 </li>
 <li class="listitem">
 <p>use the appropriate Add Elements (+ icon) for Precondition or Postcondition, or the Body condition
 										<span class="bold"><strong>...</strong></span> browser to locate the constraint
 									</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>define the Specification of the Constraint with OCL text</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select the Constraint</p>
 </li>
 <li class="listitem">
 <p>type F2 (or click again) to open the Essential OCL editor</p>
 </li>
 <li class="listitem">
 <p>enter the required constraint text</p>
 </li>
 <li class="listitem">
 <p>click outside the editor to close</p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>Note that the context of Operation Constraints must be specified by assigning a Constraint to one of the precondition/postcondition/bodycondition roles. Assignment of the context of the constraint directly fails to allocate the constraint to its role.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1710-operation-constraints.png"></div>
 <p>

 </p>
 <p>Note that in Papyrus 1.0, there is no stereotype display to indicate the precondition/postcondition/body-condition role.</p>
 <p>Note that the OCL expressions for preconditions and postconditions should be Boolean-valued. The result-valued body-expression form should be used for a body-condition.</p>
 <p>The owning type of the Operation is used as OCL&rsquo;s
 						<code class="code">self</code> context.
 					</p>
 <p>The Operation should be a query if a body-condition is provided.</p>
 <p>

 <span class="italic">In Luna, use of
 							<code class="code">result</code> within postconditions incorrectly reports an unknown property. The error can be ignored.
 						</span>

 </p>
 </div>
 <div class="section" title="Property Initializers">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinPapyrus-Property-Initializers"></a>Property Initializers</h4>
 </div>
 </div>
 </div>
 <p>An OpaqueExpression whose value is an OCL expression string can be used to define the default or derived value of a Property initializer.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>select the Property to make the Properties View relevant</p>
 </li>
 <li class="listitem">
 <p>click the Create a new Object (+ icon) for the Default value</p>
 </li>
 <li class="listitem">
 <p>Select OpaqueExpression from the menu</p>
 </li>
 <li class="listitem">
 <p>click the Add elements (+ icon) for the Language</p>
 </li>
 <li class="listitem">
 <p>select OCL in the left pane and click the right arrow to move to the right pane</p>
 </li>
 <li class="listitem">
 <p>click OK</p>
 </li>
 <li class="listitem">
 <p>enter the OCL text in the large pane</p>
 </li>
 <li class="listitem">
 <p>click OK</p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1710-property-constraint.png"></div>
 <p>

 </p>
 <p>

 <span class="italic">Unfortunately, in Luna, the context does not appear to be correctly set for editor, so there is an error on
 							<code class="code">self</code> and no syntax help.
 						</span>

 </p>
 </div>
 <div class="section" title="Profile Constraint">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinPapyrus-Profile-Constraint"></a>Profile Constraint</h4>
 </div>
 </div>
 </div>
 <p>A Profile Constraint is very similar to a Class Invariant. However since the Profile is Constraint is drawn at M2, it may be evaluated at M1 to check a UML Class Diagram for consistency. In contrast a Class Invariant drawn at M1, may be evaluated by user tooling at M0 to validate user models. It is specified in Papyrus, by:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>create a Constraint Node on a Profile Diagram</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select Constraint on palette</p>
 </li>
 <li class="listitem">
 <p>click on diagram where you want it</p>
 </li>
 <li class="listitem">
 <p>click on the Stereotype you want as the Constraint context</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>optionally replace the auto-generated Constraint name</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select the Constraint</p>
 </li>
 <li class="listitem">
 <p>type a new name in the Properties View</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>define the Specification of the Constraint with OCL text</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select the Constraint</p>
 </li>
 <li class="listitem">
 <p>type F2 (or click again) to open the Essential OCL editor</p>
 </li>
 <li class="listitem">
 <p>enter the required constraint text</p>
 </li>
 <li class="listitem">
 <p>click outside the editor to close</p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1710-profile-constraint.png"></div>
 <p>

 </p>
 <p>The OCL text can also be edited within the Properties View.</p>
 </div>
 </div>
 <div class="section" title="State Machine Diagram">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLinPapyrus-StateMachine-Diagram"></a>State Machine Diagram</h3>
 </div>
 </div>
 </div>
 <p>The primary element of a StateMachine diagram is the StateMachine, which is a Type, but does not normally have Properties.
 					A StateMachine should therefore be defined as a nested type of a containing type. This may be achieved within Papyrus Model Explorer
 					by dragging the StateMachine to be a child of a Class.</p>
 <div class="section" title="Statemachine Constraint">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinPapyrus-State-Constraint"></a>Statemachine Constraint</h4>
 </div>
 </div>
 </div>
 <p>A Constraint may be applied to a Statemachine in the same way as for a Class to specify an invariant of the Statemachine.</p>
 </div>
 <div class="section" title="Statemachine Transition Guard">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinPapyrus-Transition-Guard"></a>Statemachine Transition Guard</h4>
 </div>
 </div>
 </div>
 <p>The guard condition of a Statemachine Transition may be specified by associating a Constraint with a Transition. The Transition should already exist and the Statemachine should be a nested type of a suitable type for OCL&rsquo;s
 						<code class="code">self</code>.
 						The guard condition is drawn in Papyrus by
 					</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>create a Constraint Node on a StateMachine Diagram</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select Constraint on palette</p>
 </li>
 <li class="listitem">
 <p>click on diagram where you want it</p>
 </li>
 <li class="listitem">
 <p>optionally enter the required constraint text</p>
 </li>
 <li class="listitem">
 <p>type Esc to close editor</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>optionally replace the auto-generated Constraint name</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select the Constraint, if not already selected</p>
 </li>
 <li class="listitem">
 <p>type a new name in the Properties View</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>define the Constraint Context</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select the Constraint, if not already selected</p>
 </li>
 <li class="listitem">
 <p>use the Context
 										<span class="bold"><strong>...</strong></span> browser in the Properties View to locate the transition
 									</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>define the Specification of the Constraint with OCL text</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>select the Constraint, if not already selected</p>
 </li>
 <li class="listitem">
 <p>type F2 (or click again) to open the Essential OCL editor</p>
 </li>
 <li class="listitem">
 <p>enter the required constraint text</p>
 </li>
 <li class="listitem">
 <p>click outside the editor to close</p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1710-transition-guard.png"></div>
 <p>

 </p>
 <p>The required Transition is specified as the Guard of the Transition.</p>
 <p>The owning type of the Statemachine defines OCL&rsquo;s
 						<code class="code">self</code>. In the absence of an owning type
 						<code class="code">self</code> will be undefined and OCL constraint validation will fail. You must therefore ensure that the StateMachine has a Class parent and that the Class has the required properties;
 						<code class="code">name</code> for this example. Once Class and properties are defined using a Class diagram. The
 					</p>
 </div>
 </div>
 </div>
 <div class="section" title="OCL Constraint Examples for UML (using Papyrus)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OCLExamplesforUML"></a>OCL Constraint Examples for UML (using Papyrus)</h2>
 </div>
 </div>
 </div>
 <p>(This documentation applies to Papyrus 3.0.0 and Eclipse Oxygen.)</p>
 <p>The
 				<a class="link" href="#OCLinPapyrus" title="OCL in UML (using Papyrus)">OCL in UML (using Papyrus)</a> section shows how Papyrus may be used to create and maintain OCL expressions that enrich a UML model or profile.
 			</p>
 <p>In this section we show how some simple and not so simple OCL examples can solve useful specification problems.</p>
 <p>OCL Constraints may be specified at any meta-level. A class-level defines the types and properties that are used by the instance-level. The OCL constraints validate that the instances are compliant. The OCL therefore executes on instances of the instance-level using the types and properties of the class-level.</p>
 <p>A Constraint may be used just to document the design intent, but given an appropriate environment a constraint may be tested and/or used to verify the consistency of models. This may be</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>a test model defined by using UML InstanceSpecification to instantiate the UML model.</p>
 </li>
 <li class="listitem">
 <p>a live model created by instantiating the Ecore equivalent of the UML model</p>
 </li>
 <li class="listitem">
 <p>a UML model that conforms to a UML profile</p>
 </li>
 </ul>
 </div>
 <p>In all cases when a validation of the model is requested, the validator attempts to execute each possible constraint on each possible instance to which it applies. When executing the constraint, the validator binds the
 				<code class="code">self</code> variable to the instance to be validated. The type of
 				<code class="code">self</code> is determined by the context of the Constraint. In Papyrus this context is determined by the non-Constraint end of the
 				<code class="code">&lt;&lt;context&gt;&gt;</code> link from Constraint. The result of evaluating a Constraint should
 				<code class="code">true</code> or
 				<code class="code">false</code>. If
 				<code class="code">true</code>, the constraint is satisfied. If
 				<code class="code">false</code> the constraint is violated and some diagnostic should be shown to the user.
 			</p>
 <p>In
 				<a class="link" href="#OCLM1Constraints" title="Model Constraints">Model Constraints</a>, we provide examples that apply to the elements of UML model. The Constraints are evaluated on the instances of the model. How violations are diagnosed depends on the synthesis of model instances and the corresponding run-time environment.
 			</p>
 <p>In
 				<a class="link" href="#OCLM2Constraints" title="Profile Constraints">Profile Constraints</a>, we provide examples that apply to the elements of a UML profile. The Constraints are evaluated to verify consistent usage of the elements in the model. Violations are diagnosed within the UML editor.
 			</p>
 <div class="section" title="Model Constraints">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLM1Constraints"></a>Model Constraints</h3>
 </div>
 </div>
 </div>
 <div class="section" title="Simple Metamodel">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="SimpleMetamodel"></a>Simple Metamodel</h4>
 </div>
 </div>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1720-persons-metamodel.png"></div>
 <p>

 </p>
 <p>The figure shows a metamodel specified in UML as a Papyrus Class Diagram. The upper half shows a simple metamodel comprising just a
 						<code class="code">Person</code> class. A
 						<code class="code">Person</code> has a
 						<code class="code">String</code>-valued
 						<code class="code">name</code> and may have a
 						<code class="code">partner</code>,
 						<code class="code">parents</code> and/or
 						<code class="code">children</code>.
 					</p>
 <p>Some constraints such as the
 						<code class="code">parents[0..2]</code> limitation on the the number of parents to 2 may be specified directly using UML capabilities without any use of OCL. But many more challenging restrictions require OCL constraints, for which five examples are provided in the lower half of the figure.
 					</p>
 </div>
 <div class="section" title="Scalar Constraints">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ScalarConstraints"></a>Scalar Constraints</h4>
 </div>
 </div>
 </div>
 <p>To help understand the way in which OCL evaluates, it is helpful to consider some instances that conform to the constrained model</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1720-persons-scalars.png"></div>
 <p>

 </p>
 <p>The figure shows a model comprising three persons whose names are
 						<code class="code">father</code>,
 						<code class="code">mother</code> and
 						<code class="code">baby</code>.
 					</p>
 <p>The notation in the figure is similar to a UML Object Diagram.
 						<span class="emphasis"><em>This should be drawable in Papyrus, unfortunately a number of bugs prevent this in the Oxygen release of Papyrus</em></span>. The notation deviates slightly from UML by only underlining type name, and by using rounded rectangles to distinguish DataType values from Class instances.
 					</p>
 <p>The three instances of
 						<code class="code">Person</code> are shown as three rectangles, with an instance name such as
 						<code class="code">pa</code> and underlined type
 						<code class="code">Person</code>. The three names are shown as rounded rectangles with values such as
 						<code class="code">father</code> and type
 						<code class="code">String</code>. The association between a
 						<code class="code">Person</code> instance and their
 						<code class="code">name</code> is shown by a directed link from the
 						<code class="code">Person</code> instance to the value. The link is labelled with the relationship role which is
 						<code class="code">name</code>.
 					</p>
 <p>The
 						<code class="code">partner</code> relationship role is similarly shown by a directed link from
 						<code class="code">pa</code> to
 						<code class="code">ma</code> and vice-versa.
 					</p>
 <div class="section" title="NameIsAlphabetic">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="NameIsAlphabetic"></a>
 							<code class="code">NameIsAlphabetic</code>

 </h5>
 </div>
 </div>
 </div>
 <p>The simplest example constraint uses a regular expression to specify that the
 							<code class="code">name</code> must consist of just alphabetic characters.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">self.name.matches('[a-zA-Z]*')<br>

 </code>
 </p>
 </div>
 <p>The
 							<code class="code">.</code> is the OCL Object navigation operator. It separates a cascade of navigation steps each of which returns a result value.
 						</p>
 <p>Evaluation starts at
 							<code class="code">self</code>, which rather like
 							<code class="code">this</code> in Java, is bound to an object whose type is the context of the Constraint. The result is therefore a
 							<code class="code">Person</code> object such as
 							<code class="code">pa</code>.
 						</p>
 <p>The property navigation step
 							<code class="code">name</code>, traverses the relationship whose role is
 							<code class="code">name</code>. The navigation steps from
 							<code class="code">pa</code> to the
 							<code class="code">father</code> value. The result is a String comprising
 							<code class="code">father</code>.
 						</p>
 <p>The operation call step
 							<code class="code">matches('[a-zA-Z]*')</code>, executes the regular expression matching function using the provided regex. The final result is
 							<code class="code">true</code> or
 							<code class="code">false</code>.
 						</p>
 </div>
 <div class="section" title="NoSelfPartnership">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="NoSelfPartnership"></a>
 							<code class="code">NoSelfPartnership</code>

 </h5>
 </div>
 </div>
 </div>
 <p>Another very simple example constraint checks that the
 							<code class="code">partner</code> relationship does not have the same
 							<code class="code">Person</code> as both its source and target.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">self.partner&nbsp;&lt;&gt;&nbsp;self<br>

 </code>
 </p>
 </div>
 <p>The OCL comprises two navigation expressions separated by the infix
 							<code class="code">&lt;&gt;</code> operator.
 						</p>
 <p>The first,
 							<code class="code">self.partner</code>, navigates from
 							<code class="code">self</code> to compute a result comprising the
 							<code class="code">partner</code> of the
 							<code class="code">self</code> context instance.
 						</p>
 <p>The second,
 							<code class="code">self</code> just returns the context instance.
 						</p>
 <p>The not-equals
 							<code class="code">&lt;&gt;</code> infix operator compares its preceding and following arguments and provides a
 							<code class="code">true</code> result when the arguments are not-equal,
 							<code class="code">false</code> when equal.
 						</p>
 </div>
 </div>
 <div class="section" title="Collection Constraints">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CollectionConstraints"></a>Collection Constraints</h4>
 </div>
 </div>
 </div>
 <p>The one-to-one relationships between objects and values have a simple implementation typically involving a pointer. One-to-many and many-to-many relationships are more complex since a collection of values is involved.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1720-persons-collections.png"></div>
 <p>

 </p>
 <p>The figure above elaborates the earlier figure to show the to-many relationships. The figure also uses a simpler representation of the object to value relationships by embedding each
 						<code class="code">name</code> value within its
 						<code class="code">Person</code> instance. One-to-one object relationships such as
 						<code class="code">partner</code> are unaffected. To-many relationships such as
 						<code class="code">parents</code> are shown using a multi-object drawn as three overlaid rectangles. Each multi-object is typically a collection owned by the relationship source and shown by a solid arrow labelled with the relationship name. Each element of the collection is identified by a dashed arrow.
 						<code class="code">child</code> therefore has two
 						<code class="code">parents</code>;
 						<code class="code">pa</code> and
 						<code class="code">ma</code>. Many-to-many relationships are convently realized as independent one-to-many relationships in each direction. The
 						<code class="code">children</code> opposite of
 						<code class="code">parents</code> is therefore shown by a
 						<code class="code">children</code> multi-object for each parent identifying the one child.
 					</p>
 <p>When Ecore is used to implement UML, the multi-object is realized in exactly this way by an
 						<code class="code">EList</code>.
 					</p>
 <p>OCL provides an ability to use these multi-objects within expressions. The multi-object is a
 						<code class="code">Collection</code>, or more specifically a
 						<code class="code">Bag</code>,
 						<code class="code">OrderedSet</code>,
 						<code class="code">Sequence</code> or
 						<code class="code">Set</code> depending on whether the to-many-relationship is specified to be
 						<code class="code">ordered</code> and/or
 						<code class="code">unique</code>.
 					</p>
 <p>In OCL,
 						<code class="code">-&gt;</code> is the collection navigation operator that enables an evaluation to exploit all the target objects.
 					</p>
 <div class="section" title="EachChildHasTwoParents">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="EachChildHasTwoParents"></a>EachChildHasTwoParents</h5>
 </div>
 </div>
 </div>
 <p>Each child should have two parents, but in any finite model there must be some
 							<code class="code">Person</code> instances for which the parents are omitted. Hence the model specifies a [0..2] multiplicity rather than precisely [2..2]. We may remedy this deficiency with an OCL constraint.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">self.children-&gt;forAll(child&nbsp;|&nbsp;child.parents-&gt;size()&nbsp;=&nbsp;2)<br>

 </code>
 </p>
 </div>
 <p>The
 							<code class="code">self</code> and
 							<code class="code">children</code> navigate from the context object to locate the collection of all children of the context instance as the navigation result.
 						</p>
 <p>The
 							<code class="code">-&gt;</code> collection operator and the subsequent
 							<code class="code">forAll(child | ...)</code> iteration cause an iteration to be performed over the children, assigning each child in turn to the
 							<code class="code">child</code> iterator variable. The
 							<code class="code">...</code> iterator body is evaluated for each child and accumulated so that the result of the
 							<code class="code">forAll</code> is only
 							<code class="code">true</code> if the body evaluation for each
 							<code class="code">child</code> is also
 							<code class="code">true</code>.
 						</p>
 <p>The iteration body navigates from each
 							<code class="code">child</code> to select the collection of all of its
 							<code class="code">parents</code>. Then the
 							<code class="code">-&gt;</code> collection navigation operator invokes the collection operation
 							<code class="code">size()</code> to compute the size of the collection. This size is compared using the
 							<code class="code">=</code> (equals) operator to the constant
 							<code class="code">2</code>. The iteration body therefore returns
 							<code class="code">false</code> unless the number of parents is equal to 2.
 						</p>
 <p>This example can be written more compactly as</p>
 <div class="literallayout">
 <p>
 <code class="code">children-&gt;forAll(parents-&gt;size()&nbsp;=&nbsp;2)<br>

 </code>
 </p>
 </div>
 <p>since an implicit iterator is the default source for navigation within an iteration body, and
 							<code class="code">self</code> is the default outside.
 						</p>
 </div>
 <div class="section" title="AcyclicAncestry">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="AcyclicAncestry"></a>AcyclicAncestry</h5>
 </div>
 </div>
 </div>
 <p>The instances of a user model often form an acyclic graph. It is therefore desirable to specify this as an OCL constraint so that any cycles are detected by an OCL model validator. This is fairly easy to specify with the help of the OCL transitive closure iteration.</p>
 <div class="literallayout">
 <p>
 <code class="code">self.parents-&gt;closure(parent&nbsp;|&nbsp;parent.parents)-&gt;excludes(self)<br>

 </code>
 </p>
 </div>
 <p>Once again the
 							<code class="code">self.parents</code> navigation returns the collection of all parents of the context instance. This collection is used as a seed from which  the
 							<code class="code">closure(parent | ... )</code> collection iteration grows the final result by repeatedly aggregating the result of the
 							<code class="code">...</code> body evaluation. Each element of the interim result is bound to the
 							<code class="code">parent</code> iterator until there are no values left in the result for which the iteration body has not been evaluated.
 						</p>
 <p>The
 							<code class="code">parent.parents</code> iteration body just returns all parents of a given parent so that the closure progressively aggregates the grandparents then great-grandparents, then ...
 						</p>
 <p>Once the
 							<code class="code">closure</code> completes, it returns a
 							<code class="code">Set</code> (or
 							<code class="code">OrderedSet</code>) of all ancestors which is passed to the the
 							<code class="code">excludes</code> Collection operator to confirm that the
 							<code class="code">self</code> instance is not an ancestor of itself.
 						</p>
 <p>This example can be written more compactly as</p>
 <div class="literallayout">
 <p>
 <code class="code">parents-&gt;closure(parents)-&gt;excludes(self)<br>

 </code>
 </p>
 </div>
 </div>
 <div class="section" title="EachChildsParentsArePartners">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="EachChildsParentsArePartners"></a>EachChildsParentsArePartners</h5>
 </div>
 </div>
 </div>
 <p>A user model may not always allow arbitrary relationships between its instances. An OCL constraint can impose discipline, and within a more complex OCL constraint one or more let-variables may provide structure that aids readability.</p>
 <p>In our example we may wish to impose a requirement that the two parents of a child are partners.</p>
 <div class="literallayout">
 <p>
 <code class="code">let&nbsp;selfAndPartner&nbsp;=&nbsp;self.oclAsSet()-&gt;including(self.partner)&nbsp;in<br>
 self.children-&gt;forAll(child&nbsp;|&nbsp;selfAndPartner-&gt;includesAll(child.parents))<br>

 </code>
 </p>
 </div>
 <p>The
 							<code class="code">let selfAndPartner ... in ...</code> assigns the value of a first
 							<code class="code">...</code> expression to the
 							<code class="code">selfAndPartner</code> let-variable so that
 							<code class="code">selfAndPartner</code> can then be used in the evaluation of the second
 							<code class="code">...</code> expression that provides the final result. The let-variable allows a sub-computation to be re-used many times, or just to be assigned to a readable name.
 						</p>
 <p>The let-variable is computed by first using
 							<code class="code">self.oclAsSet()</code> to compute a single element Set containing
 							<code class="code">self</code> It then uses the collection operation
 							<code class="code">including(self.partner)</code> to compute another set containing all (one) elements of the original set and also including another element. The result is therefore a set of the two elements,
 							<code class="code">self</code> and
 							<code class="code">self.partner</code>.
 						</p>
 <p>As before
 							<code class="code">self.children-&gt;forAll(child | ...)</code> binds each child to the
 							<code class="code">child</code> iterator and requires that the
 							<code class="code">...</code> body evaluates to
 							<code class="code">true</code> for all values of
 							<code class="code">child</code>. The body verifies that the pair of persons cached in the
 							<code class="code">selfAndPartner</code> includes each person identified by
 							<code class="code">child.parents</code>.
 						</p>
 <p>This example can be written more compactly as</p>
 <div class="literallayout">
 <p>
 <code class="code">let&nbsp;selfAndPartner&nbsp;=&nbsp;self-&gt;including(partner)&nbsp;in<br>
 children-&gt;forAll(selfAndPartner&nbsp;=&nbsp;parents)<br>

 </code>
 </p>
 </div>
 <p>The more compact form exploits an implicit invocation of
 							<code class="code">oclAsSet()</code> that occurs when a
 							<code class="code">-&gt;</code> collection navigation operator has a non-collection as its source.
 						</p>
 <p>Eliminating the explicit
 							<code class="code">child</code> iterator from the
 							<code class="code">forAll</code> iteration is permissible but perhaps unwise since an occasional OCL user may struggle to understand whether the final
 							<code class="code">parents</code> is
 							<code class="code">self.parents</code> or
 							<code class="code">child.parents</code>.
 						</p>
 </div>
 </div>
 </div>
 <div class="section" title="Profile Constraints">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLM2Constraints"></a>Profile Constraints</h3>
 </div>
 </div>
 </div>
 <p>A UML Profile provides an ability to extend an existing metamodel by defining Stereotypes that may be added to elements of the metamodel. The
 					<code class="code">Ecore.profile.uml</code> which annotates
 					<code class="code">UML.uml</code> to define the Eclipse UML support is a good example of such usage. The contrived example here that extends a single class metamodel would be much better realized by a new metamodel.
 				</p>
 <div class="section" title="Example Profile">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ExampleProfile"></a>Example Profile</h4>
 </div>
 </div>
 </div>
 <p>Our contrived example provides two forms of extension,
 						<code class="code">Gender</code> and
 						<code class="code">Role</code> intended for a
 						<code class="code">Person</code> element, but since we are defining a profile we must define the extension for
 						<code class="code">Person</code>'s metaclass which is
 						<code class="code">Class</code>. We also define another extension,
 						<code class="code">Vehicle</code>, that is sensible for a
 						<code class="code">Class</code> but clearly stupid for a
 						<code class="code">Person</code>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1720-persons-profile.png"></div>
 <p>

 </p>
 <p>A
 						<code class="code">Person</code> may have a
 						<code class="code">Gender</code> defined as an abstract stereotype from which the concrete
 						<code class="code">Male</code> and
 						<code class="code">Female</code> stereotypes derive.
 					</p>
 <p>A
 						<code class="code">Person</code> may have one or more
 						<code class="code">Role</code>'s defined as an abstract stereotype from which the concrete
 						<code class="code">Astronaut</code> and
 						<code class="code">Priest</code> stereotypes derive. A
 						<code class="code">Priest</code> provides an additional
 						<code class="code">priesthood</code> enumeration property that identifies the religious affiliation of the priest.
 					</p>
 <p>These definitions are drawn as an extension link from a base stereotype such as
 						<code class="code">Gender</code>, to a metaclass, such as
 						<code class="code">Class</code>. The link is a UML
 						<code class="code">Extension</code> that is a form of
 						<code class="code">Association</code> and so has two automatically synthesized
 						<code class="code">Property</code> elements for its ends. The property role names are derived by applying
 						<code class="code">base_</code> or
 						<code class="code">extension_</code> prefixes to the target class/metaclass names. The
 						<code class="code">base_Class</code> property therefore identifies the
 						<code class="code">Class</code> metaclass end of the
 						<code class="code">Extension</code>, and the
 						<code class="code">extension_Gender</code> identifies the
 						<code class="code">Gender</code> end.
 					</p>
 <p>The
 						<code class="code">extension_</code> property has a multiplicity for which [0..1] specifies that at most one application of the
 						<code class="code">Gender</code> stereotype is permissible. Alternatively a [0..*] multiplicity specifies that zero or more applications of the
 						<code class="code">Role</code> stereotype are possible; a priest may also be an astronaut. Specification of non-zero lowerbounds is possible but not generally appropriate since the application is to the metaclass. Mandating that a
 						<code class="code">Gender</code> is always applied leads to stupidities if a completely independent class such as an
 						<code class="code">Road</code> are also modeled.
 					</p>
 <p>The extension multiplicity provides a very limited imposition of design rules on the use of the stereotypes. Generally much more complex rules requiring OCL constraints are required. Four examples are shown and explained later.</p>
 <p>

 <span class="emphasis"><em>(The Oxygen release of Papyrus provides a misleading editing interface for stereotype multiplicities. Use only the advanced properties after selecting the extension in the Model Explorer View)</em></span>.
 					</p>
 </div>
 <div class="section" title="Example Profiled Model">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ExampleProfiledModel"></a>Example Profiled Model</h4>
 </div>
 </div>
 </div>
 <p>The application of stereotypes is relatively straightforward and not the topic of this section. A profile is applied to the model, so that its stereotypes can be applied to the elements.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1720-persons-profiled.png"></div>
 <p>

 </p>
 <p>Applied stereotypes are shown within guilemets. The example above shows definition of a derived
 						<code class="code">Person</code> class named
 						<code class="code">Priestess</code> to which the
 						<code class="code">Female</code> and
 						<code class="code">Priest</code> stereotypes have been applied. Not shown in the diagram, is the definition of the
 						<code class="code">Priest::priesthood</code> metaproperty with the
 						<code class="code">RABBI</code> value.
 					</p>
 <p>The UML representation is deceptively simple and consequently rather confusing when writing OCL constraints. We need to look at the equivalent object model that the OCL evaluation uses.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1720-persons-applied.png"></div>
 <p>

 </p>
 <p>The figure shows just the
 						<code class="code">Priestess</code> class. In the centre, an instance of the
 						<code class="code">Class</code> metaclass is instantiated as a
 						<code class="code">Class</code> named
 						<code class="code">Priestess</code> with the inherited String-valued
 						<code class="code">Property</code> named
 						<code class="code">name</code>. Each
 						<code class="code">Stereotype</code> metaclass is instantiated as an element without a type specification. The elements are named
 						<code class="code">Priest</code> and
 						<code class="code">Female</code>.
 					</p>
 <p>

 <span class="emphasis"><em>The type specification is missing because the UML specification has no primary need for the concept of a stereotype instance. This omission leads to a complexity in the XMI serialization for UML. The omitted type is indicated by the guilemets surrounding the names.</em></span>

 </p>
 <p>The relationships between
 						<code class="code">Priestess</code> and
 						<code class="code">&laquo;Female&raquo;</code> show the synthesized
 						<code class="code">base_Class</code> and
 						<code class="code">extension_Gender</code> relationships. Note that it is
 						<code class="code">extension_Gender</code> rather than
 						<code class="code">extension_Female</code> since the profile defined
 						<code class="code">Gender</code> as an extension of the
 						<code class="code">Class</code> metaclass.
 						<code class="code">Female</code> is a derivation of the defined extension.
 					</p>
 <p>The relationships between
 						<code class="code">Priestess</code> and
 						<code class="code">&laquo;Priest&raquo;</code> are more complex since more than one
 						<code class="code">Role</code> may be applied. The
 						<code class="code">extension_Role</code> therefore identifies a collection of zero or more
 						<code class="code">Role</code>'s. The example shows that the collection contains just the one
 						<code class="code">&laquo;Priest&raquo;</code> element.
 					</p>
 <p>We may now examine some example constraints to see how this model is used by constraint evaluation.</p>
 <div class="section" title="MaleOrFemale">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="MaleOrFemale"></a>
 							<code class="code">MaleOrFemale</code>

 </h5>
 </div>
 </div>
 </div>
 <p>A simple example constraint on an abstract
 							<code class="code">&laquo;Gender&raquo;</code> stereotype confirms that only one of the
 							<code class="code">&laquo;Female&raquo;</code> or
 							<code class="code">&laquo;Male&raquo;</code> stereotypes is applied.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">let&nbsp;gender&nbsp;=&nbsp;self.base_Class.extension_Gender&nbsp;in&nbsp;<br>
 gender.oclIsKindOf(Male)&nbsp;&lt;&gt;&nbsp;gender.oclIsKindOf(Female)<br>

 </code>
 </p>
 </div>
 <p>The navigation starts with
 							<code class="code">self</code> bound to a
 							<code class="code">&laquo;Gender&raquo;</code> instance since that is the
 							<code class="code">&laquo;context&raquo;</code> of the Constraint definition. Navigation to
 							<code class="code">base_Class</code> locates the instance of
 							<code class="code">Class</code> to which the stereotype is provided. The further navigation to
 							<code class="code">extension_Gender</code> locates a
 							<code class="code">&laquo;Gender&raquo;</code> instance for any corresponding application of the stereotype. This instance is saved in the
 							<code class="code">gender</code> let-variable.
 						</p>
 <p>The subsequent operation navigation from
 							<code class="code">gender</code> using
 							<code class="code">oclIsKindOf(Male)</code> returns
 							<code class="code">true</code> if
 							<code class="code">gender</code> is a
 							<code class="code">Male</code> stereotype instance,
 							<code class="code">false</code> otherwise. The similar test for
 							<code class="code">oclIsKindOf(Female)</code> is compared so that the constraint is only
 							<code class="code">true</code> when the applied stereotypes differ.
 						</p>
 <p>This Constraint is somewhat redundant since the at-most-one multiplicity on a
 							<code class="code">&laquo;Gender&raquo;</code> stereotype inhibits any double application. The let-variable
 							<code class="code">gender</code> is therefore always the same as
 							<code class="code">self</code>. This constraint can therefore be written more compactly as:
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">true<br>

 </code>
 </p>
 </div>
 </div>
 <div class="section" title="GenderIsRequired">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="GenderIsRequired"></a>
 							<code class="code">GenderIsRequired</code>

 </h5>
 </div>
 </div>
 </div>
 <p>A more useful constraint mandates that every non-abstract class to which a
 							<code class="code">&laquo;Role&raquo;</code> is applied also has an application of the
 							<code class="code">&laquo;Gender&raquo;</code> stereotype.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">not&nbsp;self.base_Class.isAbstract&nbsp;implies<br>
 self.base_Class.extension_Gender&nbsp;&lt;&gt;&nbsp;null<br>

 </code>
 </p>
 </div>
 <p>When this is evaluated for our single instance example model, evaluation starts with
 							<code class="code">self</code> bound to the
 							<code class="code">&laquo;Priest&raquo;</code> stereotype instance since the
 							<code class="code">&laquo;context&raquo;</code> of the constraint definition is the
 							<code class="code">Role</code> from which
 							<code class="code">Priest</code> derives.
 						</p>
 <p>

 <code class="code">self.base_Class</code> navigates from the
 							<code class="code">&laquo;Priest&raquo;</code> stereotype instance to the
 							<code class="code">Priestess</code> class instance, where the
 							<code class="code">isAbstract</code> navigation is used to test the
 							<code class="code">UML::Class::isAbstract</code> property to determine whether
 							<code class="code">Priestess</code> is abstract or not.
 						</p>
 <p>The
 							<code class="code">x implies y</code> infix operator is often more readable that
 							<code class="code">(not x) or y</code>; it conveniently short-circuits evaluation of a garbage second expression when the first expression is
 							<code class="code">false</code>. In this example the subsequent evaluation is bypassed for instances of abstract classes.
 						</p>
 <p>The
 							<code class="code">self.base_Class.extension_Gender</code> navigates first to the
 							<code class="code">Priestess</code> class instance and then on to a
 							<code class="code">&laquo;Gender&raquo;</code> stereotype instance. This navigation returns a non-null object if there is such an instance, or
 							<code class="code">null</code> if there is not. The
 							<code class="code">&lt;&gt; null</code> comparison therefore returns
 							<code class="code">true</code> when a
 							<code class="code">Gender</code> stereotype has been applied; or
 							<code class="code">false</code> when not-applied.
 						</p>
 <p>Note that the examples specify a relevant stereotype as the
 							<code class="code">&laquo;context&raquo;</code>. It is possible to write an identical constraint when the
 							<code class="code">Class</code> metaclass is specified as the
 							<code class="code">&laquo;context&raquo;</code>.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">not&nbsp;isAbstract&nbsp;implies&nbsp;<br>
 extension_Role-&gt;notEmpty()&nbsp;implies<br>
 extension_Gender&nbsp;&lt;&gt;&nbsp;null<br>

 </code>
 </p>
 </div>
 <p>However this is inefficient since it must be executed for all possible classes where it performs a double test &lsquo;any Role&rsquo; then &lsquo;check Gender&rsquo;. By defining the constraint on the
 							<code class="code">Role</code>, the first test is performed for free. Redundant evaluations for e.g.
 							<code class="code">Road</code> elements are avoided. Of course a separate constraint that
 							<code class="code">Role</code> should only be applied to
 							<code class="code">Person</code> may be desirable.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">base_Class.oclIsKindOf(Person)<br>

 </code>
 </p>
 </div>
 </div>
 <div class="section" title="CatholicPriestsAreMale">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="CatholicPriestsAreMale"></a>
 							<code class="code">CatholicPriestsAreMale</code>

 </h5>
 </div>
 </div>
 </div>
 <p>Stronger constraints may mandate a business rule such as requiring that
 							<code class="code">CATHOLIC</code> priests are male.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">self.priesthood&nbsp;=&nbsp;Priesthood::CATHOLIC&nbsp;implies<br>
 self.base_Class.extension_Gender.oclIsKindOf(Male)<br>

 </code>
 </p>
 </div>
 <p>The left hand side of the
 							<code class="code">implies</code> restricts the constraint to the case where the
 							<code class="code">priesthood</code> meta-property has been assigned the
 							<code class="code">CATHOLIC</code> enumeration value. In our single class example, a
 							<code class="code">Priestess</code> is assigned the value
 							<code class="code">RABBI</code> and so the test always fails. If a further
 							<code class="code">CatholicPriest</code> class is defined, this constraint then becomes useful, since the right hand side of the
 							<code class="code">implies</code> expression checks that the
 							<code class="code">&laquo;Gender&raquo;</code> stereotype instance is present and is a
 							<code class="code">&laquo;Male&raquo;</code> stereotype instance.
 						</p>
 </div>
 <div class="section" title="AtMostOnePriesthood">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="AtMostOnePriesthood"></a>
 							<code class="code">AtMostOnePriesthood</code>

 </h5>
 </div>
 </div>
 </div>
 <p>Since multiple
 							<code class="code">&laquo;Role&raquo;</code> stereotype instances are permitted, we may require a business rule to prohibit the application of two
 							<code class="code">Priest</code> stereotypes.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">self.base_Class.extension_Role-&gt;selectByKind(Priest)-&gt;size()&nbsp;=&nbsp;1<br>

 </code>
 </p>
 </div>
 <p>As before
 							<code class="code">self</code> is a
 							<code class="code">&laquo;Role&raquo;</code> stereotype instance so that navigation to
 							<code class="code">base_Class</code> identifies the
 							<code class="code">Person</code> class that has been stereotyped. The
 							<code class="code">extension_Role</code> identifies the collection of all applied
 							<code class="code">Role</code> stereotypes since multiple applications are permitted.
 						</p>
 <p>The
 							<code class="code">-&gt;</code> collection navigation operator and the collection operation
 							<code class="code">selectByKind(Priest)</code> returns a filtered  collection that selects only those stereotype instances that are, or derive from, the
 							<code class="code">Priest</code> stereotype. The further
 							<code class="code">-&gt;</code> collection navigation operator and the
 							<code class="code">size()</code> collection operation compute the size of this collection. The constraint result is
 							<code class="code">true</code> if the size equals 1;
 							<code class="code">false</code> otherwise.
 						</p>
 </div>
 <div class="section" title="->notEmpty()">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="notEmpty"></a>
 							<code class="code">-&gt;notEmpty()</code>

 </h5>
 </div>
 </div>
 </div>
 <p>The
 							<code class="code">-&gt;notEmpty()</code> collection navigation and operation is convenient to test whether one or more applications of a stereotype are present.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">self.base_Class.extension_Role-&gt;notEmpty()<br>

 </code>
 </p>
 </div>
 <p>It is not uncommon to see
 							<code class="code">-&gt;notEmpty()</code> used when at most one application is possible.
 						</p>
 <div class="literallayout">
 <p>
 <code class="code">self.base_Class.extension_Gender-&gt;notEmpty()<br>

 </code>
 </p>
 </div>
 <p>This is not wrong, but is slightly inefficient since it provokes the following automatic non-collection to set conversion.</p>
 <div class="literallayout">
 <p>
 <code class="code">self.base_Class.extension_Gender.oclAsSet()-&gt;notEmpty()<br>

 </code>
 </p>
 </div>
 <p>It is more efficient to write</p>
 <div class="literallayout">
 <p>
 <code class="code">self.base_Class.extension_Gender&nbsp;&lt;&gt;&nbsp;null<br>

 </code>
 </p>
 </div>
 </div>
 </div>
 </div>
 </div>
 <div class="section" title="User Interface">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="UserInterface"></a>User Interface</h2>
 </div>
 </div>
 </div>
 <p>The user interface comprises</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#Editors" title="Editors">Editors</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#InteractiveOCL" title="Console">Console</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#Debugger" title="Debugger (new in Luna)">Debugger</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#ValidityView" title="Validity View (new in Luna)">Validity View</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#PreferencePages" title="Workspace Preference Pages">Workspace Preference Pages</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#PropertyPages" title="Project Property Pages">Project Property Pages</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#LoadCompleteOCLResource" title="OCL->Load Document Menu Action">OCL-&gt;Load Document Menu Action</a>

 </p>
 </li>
 </ul>
 </div>
 <div class="section" title="Project Property Pages">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="PropertyPages"></a>Project Property Pages</h3>
 </div>
 </div>
 </div>
 <p>The Project Property Pages are accessible by invoking
 					<span class="bold"><strong>Properties</strong></span> from the right button context menu of a project.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1800-property-pages.png"></div>
 <p>

 </p>
 <p>In principle, it is possible to specify project-specific settings, however in practice is not often possible for application code to determine the prevailing project. Project-specific properties are therefore often ignored and may be removed in a future release.</p>
 <p>The Property pages are:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#OverallOptions" title="Overall Options">Overall Options</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#OCLinEcoreOptions" title="OCLinEcore Options">OCLinEcore editor Options</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EcoreUMLOptions" title="Ecore and UML Options">Options applicable to the Ecore and UML bindings</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#UMLOptions" title="UML Options">Options applicable to just the UML bindings</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#ModelRegistry" title="Model Registry">The Model Registry</a>

 </p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Workspace Preference Pages">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="PreferencePages"></a>Workspace Preference Pages</h3>
 </div>
 </div>
 </div>
 <p>The Workspace Preference Pages are accessible by invoking
 					<span class="bold"><strong>Preferences</strong></span> from the
 					<span class="bold"><strong>Window</strong></span> menu on the toolbar.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1800-preference-pages.png"></div>
 <p>

 </p>
 <p>The Preference pages are:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="link" href="#OverallOptions" title="Overall Options">Overall Options</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#OCLinEcoreOptions" title="OCLinEcore Options">OCLinEcore editor Options</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EcoreUMLOptions" title="Ecore and UML Options">Options applicable to the Ecore and UML bindings</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#UMLOptions" title="UML Options">Options applicable to just the UML bindings</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#SyntaxColoring" title="Syntax Coloring">Editor Syntax Coloring</a>

 </p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#EditorTemplates" title="Editor Templates">Editor Templates</a>

 </p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Overall Options">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OverallOptions"></a>Overall Options</h3>
 </div>
 </div>
 </div>
 <p>The two overall options are independent of the Ecore/UML/Pivot bindings.</p>
 <div class="section" title="Default Delegation Mode">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="DefaultDelegationMode"></a>Default Delegation Mode</h4>
 </div>
 </div>
 </div>
 <p>The Eclipse OCL project provides two execution engines which may be used to support EMF Delegates.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1810-default-delegation-mode.png"></div>
 <p>

 </p>
 <div class="section" title="http://www.eclipse.org/emf/2002/Ecore/OCL/LPG">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="LPGDelegation"></a>http://www.eclipse.org/emf/2002/Ecore/OCL/LPG</h5>
 </div>
 </div>
 </div>
 <p>EMF Delegate annotations referencing the
 							<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL/LPG</code> URI are serviced by the classic evaluator that uses the LPG parser.
 						</p>
 <p>This URI was introduced in the Indigo release.</p>
 </div>
 <div class="section" title="http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="PivotDelegation"></a>http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot</h5>
 </div>
 </div>
 </div>
 <p>EMF Delegate annotations referencing the
 							<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot</code> URI are serviced by the new experimental evaluator that uses the UML-aligned Pivot model.
 						</p>
 <p>This URI was introduced in the Indigo release and was imposed by the Indigo OCLinEcore editor.</p>
 </div>
 <div class="section" title="http://www.eclipse.org/emf/2002/Ecore/OCL">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="DefaultDelegation"></a>http://www.eclipse.org/emf/2002/Ecore/OCL</h5>
 </div>
 </div>
 </div>
 <p>EMF Delegate annotations referencing the
 							<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL</code> URI are serviced by the evaluator selected on the preference page by the
 							<a class="link" href="#DefaultDelegationMode" title="Default Delegation Mode">Default Delegation Mode</a>.
 						</p>
 <p>This URI was introduced in the Helios release and was imposed by the Helios OCLinEcore editor.</p>
 <p>Use of an Indigo or Juno editor converts the URI to use the Pivot evaluator.</p>
 <p>In Kepler, a prevailing URI in the input file is preserved, unless changed by the context menu setting. If no prevailing URI exists a default is determined by an OCLinEcore preference setting that defaults to the Pivot evaluator.</p>
 </div>
 </div>
 <div class="section" title="Code Generation Mode">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CodeGenerationMode"></a>Code Generation Mode</h4>
 </div>
 </div>
 </div>
 <p>Juno introduced an experimental ability to replace the delegated interpreted execution of OCL by direct execution of compiled Java code. This facility has been substantially improved and tested for the Kepler release.</p>
 <p>Optimisations for Luna included inlining the bodies directly into the EMF Impl classes. </p>
 <p>Mars has useful fixes and benefits from safe navigation analyses.</p>
 <p>Further optimisations are scheduled for future releases.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1810-code-generation-mode.png"></div>
 <p>

 </p>
 <p>This option may be selected to change the realization of OCL option.</p>
 <div class="section" title="Delegate for interpretation at run-time">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="CodeGenerationMode-DELEGATED"></a>Delegate for interpretation at run-time</h5>
 </div>
 </div>
 </div>
 <p>Selecting the default delegation mode retains the Helios and Indigo functionality whereby
 							<span class="bold"><strong>genmodel</strong></span> generates Java code that encodes the OCL expressions as text strings. Each expression is lazily compiled at run-time with the result being cached to reduce overheads for repeated execution.
 						</p>
 </div>
 <div class="section" title="Generate Java code in xxxBodies classes">
 <div class="titlepage">
 <div>
 <div>
 <h5 class="title">
 <a name="CodeGenerationMode-GENERATED"></a>Generate Java code in xxxBodies classes</h5>
 </div>
 </div>
 </div>
 <p>Selecting Java code generation causes
 							<span class="bold"><strong>genmodel</strong></span> to run Xtend templates that generate
 						</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>a
 									<span class="emphasis"><em>Package</em></span> Tables.java file
 								</p>
 </li>
 <li class="listitem">
 <p>inline OCL implementations within the
 									<span class="emphasis"><em>Class</em></span> Impl.java files
 								</p>
 </li>
 </ul>
 </div>
 <p>The tables file contains an optimised model representation allowing polymorphic operations to be dispatched in constant time.</p>
 <p>The implementation files contain Java code corresponding to each OCL expression defining operation bodies or property initializers.</p>
 <p>Disclaimer: the generated code is experimental has yet to be optimized and so is only about five times faster than the interpreted execution. </p>
 </div>
 </div>
 </div>
 <div class="section" title="Ecore and UML Options">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="EcoreUMLOptions"></a>Ecore and UML Options</h3>
 </div>
 </div>
 </div>
 <p>The options for the Ecore and UML bindings.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1820-ecore-uml-options.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="UML Options">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="UMLOptions"></a>UML Options</h3>
 </div>
 </div>
 </div>
 <p>The options for the UML binding.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1830-uml-options.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Model Registry">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ModelRegistry"></a>Model Registry</h3>
 </div>
 </div>
 </div>
 <p>The Model Registry is now deprecated.</p>
 </div>
 <div class="section" title="Syntax Coloring">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="SyntaxColoring"></a>Syntax Coloring</h3>
 </div>
 </div>
 </div>
 <p>The standard Xtext syntax coloring facilities are provided for each of the OCL editors.</p>
 </div>
 <div class="section" title="Editor Templates">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="EditorTemplates"></a>Editor Templates</h3>
 </div>
 </div>
 </div>
 <p>The standard Xtext editor template facilities are provided for each of the OCL editors.</p>
 </div>
 <div class="section" title="OCLinEcore Options">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLinEcoreOptions"></a>OCLinEcore Options</h3>
 </div>
 </div>
 </div>
 <p>The options for the OCLinEcore editor.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/1870-oclinecore-options.png"></div>
 <p>

 </p>
 <p>OCL embedded in Ecore can be executed with either the Classic evaluator or the new Pivot evaluator depending on the URI used to define the embedded EAnnotations. This preference determines the URI written to Ecore files when no URI was previously in use.</p>
 <p>Selecting
 					<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL</code> makes no choice and so defers to the user&rsquo;s
 					<a class="link" href="#DefaultDelegation" title="http://www.eclipse.org/emf/2002/Ecore/OCL">run-time delegation choice</a>.
 				</p>
 <p>Selecting
 					<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot</code> is recommended since the OCLinEcore editor and Pivot evaluator both use the Xtext parser. This should avoid problems whereby not all facilities of the new Pivot grammar are supported by the Classic grammic or LPG evaluator.
 				</p>
 <p>Selecting
 					<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL/LPG</code> may be appropriate if evaluation using the classic LPG evaluator is important.
 				</p>
 </div>
 </div>
 </div>
 <div class="chapter" title="Chapter&nbsp;3.&nbsp;The OCL Standard Library">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title">
 <a name="StandardLibrary"></a>Chapter&nbsp;3.&nbsp;The OCL Standard Library</h2>
 </div>
 </div>
 </div>
 <p>This documentation on the OCL Standard Library is auto-generated from the
 			org.eclipse.ocl.pivot/model/OCL-2.5.oclstdlib that defines
 			the behaviour of the Pivot evaluator and the Xtext editors. It is similar to the OCL 2.4 functionality.
 			It is a prototype of functionality for OCL 2.5 where the use of models may eliminate ambiguities.</p>
 <p>The library support for the Ecore and UML bindings in Luna has been upgraded so that the available operations
 			are similar to those documented here for the Pivot binding.</p>
 <div class="section" title="Precedences">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Precedences"></a>
 				<span class="bold"><strong>Precedences</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>

 <code class="code">NAVIGATION</code> &gt;
 				<code class="code">UNARY</code> &gt;
 				<code class="code">MULTIPLICATIVE</code> &gt;
 				<code class="code">ADDITIVE</code> &gt;
 				<code class="code">RELATIONAL</code> &gt;
 				<code class="code">EQUALITY</code> &gt;
 				<code class="code">AND</code> &gt;
 				<code class="code">OR</code> &gt;
 				<code class="code">XOR</code> &gt;
 				<code class="code">IMPLIES</code>

 </p>
 </div>
 <div class="section" title="Bag(T)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Bag"></a>
 				<span class="bold"><strong>
 					<code class="code">Bag(T)</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>A bag is a collection with duplicates allowed. That is, one object can be an element of a bag many times.
 				There is no ordering defined on the elements in a bag.
 				Bag is itself an instance of the metatype BagType.</p>
 <p>conformsTo
 				<a class="link" href="#Collection" title="Collection(T)">
 					<code class="code">Collection(T)</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>True if
 				<code class="code">self</code> and bag contain the same elements, the same number of times.
 			</p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>

 <code class="code">excluding(object : OclAny[?]) : Bag(T)</code>

 </p>
 <p>The bag containing all elements of
 				<code class="code">self</code> apart from all occurrences of object.
 			</p>
 <p>

 <code class="code">excludingAll(objects : Collection(OclAny)) : Bag(T)</code>

 </p>
 <p>The bag containing all elements of
 				<code class="code">self</code> apart from all occurrences of all objects.
 			</p>
 <p>

 <code class="code">flatten(T2)() : Bag(T2)</code>

 </p>
 <p>Redefines the Collection operation. If the element type is not a collection type, this results in the same bag as
 				<code class="code">self</code>.
 				If the element type is a collection type, the result is the bag containing all the elements of all the recursively flattened elements of
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">including(object : T[?]) : Bag(T)</code>

 </p>
 <p>The bag containing all elements of
 				<code class="code">self</code> plus object.
 			</p>
 <p>

 <code class="code">includingAll(objects : Collection(T)) : Bag(T)</code>

 </p>
 <p>The bag containing all elements of
 				<code class="code">self</code> and objects.
 			</p>
 <p>

 <code class="code">selectByKind(TT)(type : TT[?]) : Bag(TT)</code>

 </p>
 <p>

 <code class="code">selectByType(TT)(type : TT[?]) : Bag(TT)</code>

 </p>
 <p>

 <span class="bold"><strong>Iterations</strong></span>

 </p>
 <p>

 <code class="code">closure(i : T[1] | lambda : Lambda T() : Set(T)[?]) : Set(T)</code>

 </p>
 <p>The closure of applying body transitively to every distinct element of the source collection.</p>
 <p>

 <code class="code">collect(V)(i : T[?] | lambda : Lambda T() : V[?]) : Bag(V)</code>

 </p>
 <p>

 <code class="code">collectNested(V)(i : T[?] | lambda : Lambda T() : V[?]) : Bag(V)</code>

 </p>
 <p>The Bag of elements which results from applying body to every member of the source nonordered collection.</p>
 <p>

 <code class="code">reject(i : T[?] | lambda : Lambda T() : Boolean[1]) : Bag(T)</code>

 </p>
 <p>The sub-bag of the source bag for which body is
 				<code class="code">false</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">self-&gt;reject(iterator&nbsp;|&nbsp;body)&nbsp;=&nbsp;self-&gt;select(iterator&nbsp;|&nbsp;not&nbsp;body)<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>.</p>
 <p>

 <code class="code">select(i : T[?] | lambda : Lambda T() : Boolean[1]) : Bag(T)</code>

 </p>
 <p>The sub-bag of the source bag for which body is
 				<code class="code">true</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">self-&gt;select(iterator&nbsp;|&nbsp;body)&nbsp;=<br>
 self-&gt;iterate(iterator;&nbsp;result&nbsp;:&nbsp;Bag(T)&nbsp;=&nbsp;Bag{}&nbsp;|<br>
 if&nbsp;body&nbsp;then&nbsp;result-&gt;including(iterator)<br>
 else&nbsp;result<br>
 endif)<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">sortedBy(i : T[?] | lambda : Lambda T() : OclAny[?]) : Sequence(T)</code>

 </p>
 <p>Results in the Sequence containing all elements of the source collection.
 				The element for which body has the lowest value comes first, and so on.
 				The type of the body expression must have the &lt; operation defined.
 				The &lt; operation must return a Boolean value and must be transitive (i.e., if a &lt; b and b &lt; c then a &lt; c).</p>
 </div>
 <div class="section" title="Boolean">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Boolean"></a>
 				<span class="bold"><strong>
 					<code class="code">Boolean</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The standard type Boolean represents the common true/false values.
 				Boolean is itself an instance of the metatype PrimitiveType (from UML).</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>Returns
 				<code class="code">true</code> if the logical value of
 				<code class="code">self</code> is the same as the numeric value of object2,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>Returns
 				<code class="code">true</code> if the logical value of
 				<code class="code">self</code> is the not same as the numeric value of object2,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">allInstances() : Set(OclSelf)</code>

 </p>
 <p>Returns
 				<code class="code">Set{false, true}</code>.
 			</p>
 <p>

 <code class="code">and(b : Boolean[?]) : Boolean[?] invalidating validating</code>
 				precedence:
 				<code class="code">AND</code>

 </p>
 <p>

 <code class="code">false</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">false</code>.
 				Otherwise
 				<code class="code">invalid</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">invalid</code> .
 				Otherwise
 				<code class="code">null</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">null</code>.
 				Otherwise
 				<code class="code">true</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">body:&nbsp;if&nbsp;self.oclIsInvalid()&nbsp;then<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;b.oclIsInvalid()&nbsp;then&nbsp;self<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;false&nbsp;then&nbsp;false<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;self<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;self&nbsp;=&nbsp;false&nbsp;then&nbsp;false<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b.oclIsInvalid()&nbsp;then&nbsp;b<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;false&nbsp;then&nbsp;false<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;self&nbsp;=&nbsp;null&nbsp;then&nbsp;null<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;null&nbsp;then&nbsp;null<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;true<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">and2(b : Boolean[?]) : Boolean[?]</code>

 </p>
 <p>

 <code class="code">false</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">false</code>.
 				Otherwise
 				<code class="code">true</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">body:&nbsp;if&nbsp;self&nbsp;=&nbsp;false&nbsp;then&nbsp;false<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;false&nbsp;then&nbsp;false<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;true<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">implies(b : Boolean[?]) : Boolean[?] invalidating validating</code>
 				precedence:
 				<code class="code">IMPLIES</code>

 </p>
 <p>

 <code class="code">true</code> if
 				<code class="code">self</code> is
 				<code class="code">false</code>, or if
 				<code class="code">b</code> is
 				<code class="code">true</code>.
 				Otherwise
 				<code class="code">invalid</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">invalid</code>.
 				Otherwise
 				<code class="code">null</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">null</code>.
 				Otherwise
 				<code class="code">false</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">body:&nbsp;if&nbsp;self.oclIsInvalid()&nbsp;then<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;b.oclIsInvalid()&nbsp;then&nbsp;self<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;true&nbsp;then&nbsp;true<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;self<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;self&nbsp;=&nbsp;false&nbsp;then&nbsp;true<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b.oclIsInvalid()&nbsp;then&nbsp;b<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;true&nbsp;then&nbsp;true<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;self&nbsp;=&nbsp;null&nbsp;then&nbsp;null<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;null&nbsp;then&nbsp;b<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;false<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">implies2(b : Boolean[?]) : Boolean[?]</code>

 </p>
 <p>

 <code class="code">true</code> if
 				<code class="code">self</code> is
 				<code class="code">false</code>, or if
 				<code class="code">b</code> is
 				<code class="code">true</code>.
 				Otherwise
 				<code class="code">false</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">body:&nbsp;if&nbsp;self&nbsp;=&nbsp;false&nbsp;then&nbsp;true<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;true&nbsp;then&nbsp;true<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;false<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">not() : Boolean[?] validating</code>
 				precedence:
 				<code class="code">UNARY</code>

 </p>
 <p>

 <code class="code">true</code> if
 				<code class="code">self</code> is
 				<code class="code">false</code>.

 				<code class="code">false</code> if
 				<code class="code">self</code> is
 				<code class="code">true</code>.

 				<code class="code">null</code> if
 				<code class="code">self</code> is
 				<code class="code">null</code>.
 				Otherwise
 				<code class="code">invalid</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">body:&nbsp;if&nbsp;self.oclIsInvalid()&nbsp;then&nbsp;self<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;self&nbsp;=&nbsp;null&nbsp;then&nbsp;null<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;self&nbsp;=&nbsp;false<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">not2() : Boolean[1]</code>

 </p>
 <p>

 <code class="code">true</code> if
 				<code class="code">self</code> is
 				<code class="code">false</code>.
 				Otherwise
 				<code class="code">false</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">body:&nbsp;if&nbsp;self&nbsp;then&nbsp;false&nbsp;else&nbsp;true&nbsp;endif<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">or(b : Boolean[?]) : Boolean[?] invalidating validating</code>
 				precedence:
 				<code class="code">OR</code>

 </p>
 <p>

 <code class="code">true</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">true</code>.
 				Otherwise
 				<code class="code">invalid</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">invalid</code>.
 				Otherwise
 				<code class="code">null</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">null</code>.
 				Otherwise
 				<code class="code">false</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">body:&nbsp;if&nbsp;self.oclIsInvalid()&nbsp;then<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;b.oclIsInvalid()&nbsp;then&nbsp;self<br>
 			&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;true&nbsp;then&nbsp;true<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;self<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;self&nbsp;=&nbsp;true&nbsp;then&nbsp;true<br>
 			&nbsp;&nbsp;elseif&nbsp;b.oclIsInvalid()&nbsp;then&nbsp;b<br>
 			&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;true&nbsp;then&nbsp;true<br>
 			&nbsp;&nbsp;elseif&nbsp;self&nbsp;=&nbsp;null&nbsp;then&nbsp;null<br>
 			&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;null&nbsp;then&nbsp;null<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;false<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">or2(b : Boolean[?]) : Boolean[?]</code>

 </p>
 <p>

 <code class="code">true</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">true</code>.
 				Otherwise
 				<code class="code">false</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">body:&nbsp;if&nbsp;self&nbsp;=&nbsp;true&nbsp;then&nbsp;true<br>
 			&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;true&nbsp;then&nbsp;true<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;false<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">toString() : String[1]</code>

 </p>
 <p>Converts
 				<code class="code">self</code> to a string value.
 			</p>
 <p>

 <code class="code">xor(b : Boolean[?]) : Boolean[?]</code>
 				precedence:
 				<code class="code">XOR</code>

 </p>
 <p>

 <code class="code">true</code> if
 				<code class="code">self</code> is
 				<code class="code">true</code> and
 				<code class="code">b</code> is
 				<code class="code">false</code>, or if
 				<code class="code">self</code> is
 				<code class="code">false</code> and
 				<code class="code">b</code> is
 				<code class="code">true</code>.

 				<code class="code">false</code> if
 				<code class="code">self</code> is
 				<code class="code">true</code> and
 				<code class="code">b</code> is
 				<code class="code">true</code>, or if
 				<code class="code">self</code> is
 				<code class="code">false</code> and
 				<code class="code">b</code> is
 				<code class="code">false</code>.
 				Otherwise
 				<code class="code">invalid</code> if either
 				<code class="code">self</code> or
 				<code class="code">b</code> is
 				<code class="code">invalid</code>.
 				Otherwise
 				<code class="code">null</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">body:&nbsp;if&nbsp;self.oclIsInvalid()&nbsp;then&nbsp;self<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b.oclIsInvalid()&nbsp;then&nbsp;b<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;self&nbsp;=&nbsp;null&nbsp;then&nbsp;null<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elseif&nbsp;b&nbsp;=&nbsp;null&nbsp;then&nbsp;null<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else&nbsp;self&nbsp;&lt;&gt;&nbsp;b<br>
 		&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endif<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">xor2(b : Boolean[?]) : Boolean[?]</code>

 </p>
 <p>

 <code class="code">true</code> if
 				<code class="code">self</code> &lt;&gt;
 				<code class="code">b</code>
 				Otherwise
 				<code class="code">false</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">body:&nbsp;self&nbsp;&lt;&gt;&nbsp;b<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 <div class="section" title="Class">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Class"></a>
 				<span class="bold"><strong>
 					<code class="code">Class</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 </div>
 <div class="section" title="Collection(T)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Collection"></a>
 				<span class="bold"><strong>
 					<code class="code">Collection(T)</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>Collection is the abstract supertype of all collection types in the OCL Standard Library.
 				Each occurrence of an object in a collection is called an element.
 				If an object occurs twice in a collection, there are two elements.</p>
 <p>This sub clause defines the properties on Collections that have identical semantics for all collection subtypes.
 				Some operations may be defined within the subtype as well,
 				which means that there is an additional postcondition or a more specialized return value.
 				Collection is itself an instance of the metatype CollectionType.</p>
 <p>The definition of several common operations is different for each subtype.
 				These operations are not mentioned in this sub clause.</p>
 <p>The semantics of the collection operations is given in the form of a postcondition that uses the IterateExp of the IteratorExp construct.
 				The semantics of those constructs is defined in Clause 10 (&ldquo;Semantics Described using UML&rdquo;).
 				In several cases the postcondition refers to other collection operations,
 				which in turn are defined in terms of the IterateExp or IteratorExp constructs.</p>
 <p>Well-formedness rules</p>A collection cannot contain
 			<code class="code">invalid</code> values.
 			<p>context Collection
 				inv: self-&gt;forAll(not oclIsInvalid())</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Attributes</strong></span>

 </p>
 <p>

 <code class="code">lower : Integer[1]</code>

 </p>
 <p>Evaluates to the lower bound on the number of collection elements.</p>
 <p>

 <code class="code">upper : Integer[1]</code>

 </p>
 <p>Evaluates to the upper bound on the number of collection elements.</p>
 <p>

 <span class="bold"><strong>Associations</strong></span>

 </p>
 <p>

 <code class="code">elementType : T[1]</code>

 </p>
 <p>Evaluates to the type of the collection elements.</p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>True if c is a collection of the same kind as
 				<code class="code">self</code> and contains the same elements in the same quantities and in the same order,
 				in the case of an ordered collection type.
 			</p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>True if c is not equal to
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">asBag() : Bag(T)</code>

 </p>
 <p>The Bag that contains all the elements from
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">asOrderedSet() : OrderedSet(T)</code>

 </p>
 <p>An OrderedSet that contains all the elements from
 				<code class="code">self</code>, with duplicates removed,
 				in an order dependent on the particular concrete collection type.
 			</p>
 <p>

 <code class="code">asSequence() : Sequence(T)</code>

 </p>
 <p>A Sequence that contains all the elements from
 				<code class="code">self</code>, in an order dependent on the particular concrete collection type.
 			</p>
 <p>

 <code class="code">asSet() : Set(T)</code>

 </p>
 <p>The Set containing all the elements from
 				<code class="code">self</code>, with duplicates removed.
 			</p>
 <p>

 <code class="code">count(object : OclAny[?]) : Integer[1]</code>

 </p>
 <p>The number of times that object occurs in the collection
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">excludes(object : OclAny[?]) : Boolean[1]</code>

 </p>
 <p>True if object is not an element of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">excludesAll(T2)(c2 : Collection(T2)) : Boolean[1]</code>

 </p>
 <p>Does
 				<code class="code">self</code> contain none of the elements of c2 ?
 			</p>
 <p>

 <code class="code">excluding(object : OclAny[?]) : Collection(T)</code>

 </p>
 <p>The collection containing all elements of
 				<code class="code">self</code> apart from object.
 			</p>
 <p>

 <code class="code">excludingAll(objects : Collection(OclAny)) : Collection(T)</code>

 </p>
 <p>The collection containing all elements of
 				<code class="code">self</code> apart from all occurrences of all objects.
 			</p>
 <p>

 <code class="code">flatten(T2)() : Collection(T2)</code>

 </p>
 <p>If the element type is not a collection type, this results in the same collection as
 				<code class="code">self</code>.
 				If the element type is a collection type, the result is a collection containing all the elements of all the recursively flattened elements of
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">includes(object : OclAny[?]) : Boolean[1]</code>

 </p>
 <p>True if object is an element of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">includesAll(T2)(c2 : Collection(T2)) : Boolean[1]</code>

 </p>
 <p>Does
 				<code class="code">self</code> contain all the elements of c2 ?
 			</p>
 <p>

 <code class="code">including(object : T[?]) : Collection(T)</code>

 </p>
 <p>The collection containing all elements of
 				<code class="code">self</code> plus object.
 			</p>
 <p>

 <code class="code">includingAll(objects : Collection(T)) : Collection(T)</code>

 </p>
 <p>The collection containing all elements of
 				<code class="code">self</code> and objects.
 			</p>
 <p>

 <code class="code">intersection(u : UniqueCollection(T)) : Set(T)</code>

 </p>
 <p>The intersection of
 				<code class="code">self</code> and a unique collection; the set of all elements that are in both
 				<code class="code">self</code> and u.
 			</p>
 <p>

 <code class="code">intersection(c : Collection(T)) : Bag(T)</code>

 </p>
 <p>The intersection of
 				<code class="code">self</code> and bag; the bag of all elements that are in both
 				<code class="code">self</code> and c.
 			</p>
 <p>

 <code class="code">isEmpty() : Boolean[1]</code>

 </p>
 <p>Is
 				<code class="code">self</code> the empty collection?
 			</p>
 <p>Note:
 				<code class="code">null-&gt;isEmpty()</code> returns
 				<code class="code">true</code> in virtue of the implicit casting from
 				<code class="code">null</code> to
 				<code class="code">Bag{}</code>.
 			</p>
 <p>

 <code class="code">max() : T[1]</code>

 </p>
 <p>The element with the maximum value of all elements in
 				<code class="code">self</code>.
 				Elements must be of a type supporting the max operation.
 				The max operation &ndash; supported by the elements &ndash; must take one parameter of type T and be both associative and commutative.
 				UnlimitedNatural, Integer and Real fulfill this condition.
 			</p>
 <p>

 <code class="code">min() : T[1]</code>

 </p>
 <p>The element with the minimum value of all elements in
 				<code class="code">self</code>.
 				Elements must be of a type supporting the min operation.
 				The min operation &ndash; supported by the elements &ndash; must take one parameter of type T and be both associative and commutative.
 				UnlimitedNatural, Integer and Real fulfill this condition.
 			</p>
 <p>

 <code class="code">notEmpty() : Boolean[1]</code>

 </p>
 <p>Is
 				<code class="code">self</code> not the empty collection?
 			</p>
 <p>

 <code class="code">null-&gt;notEmpty()</code> returns
 				<code class="code">false</code> in virtue of the implicit casting from
 				<code class="code">null</code> to
 				<code class="code">Bag{}</code>.
 			</p>
 <p>

 <code class="code">product(T2)(c2 : Collection(T2)) : Set(Tuple(first:T[1], second:T2[1]))</code>

 </p>
 <p>The cartesian product operation of
 				<code class="code">self</code> and c2.
 			</p>
 <p>

 <code class="code">selectByKind(TT)(type : TT[?]) : Collection(TT)</code>

 </p>
 <p>

 <code class="code">selectByType(TT)(type : TT[?]) : Collection(TT)</code>

 </p>
 <p>

 <code class="code">size() : Integer[1]</code>

 </p>
 <p>The number of elements in the collection
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">sum() : T[1]</code>

 </p>
 <p>The addition of all elements in
 				<code class="code">self</code>.
 				Elements must be of an
 				<code class="code">OclSummable</code> type to provide the zero() and sum() operations.
 				The
 				<span class="emphasis"><em>sum</em></span> operation must be both associative: a.sum(b).sum&copy; = a.sum(b.sum&copy;), and commutative: a.sum(b) = b.sum(a).
 				Integer and Real fulfill this condition.
 			</p>
 <p>If the
 				<span class="emphasis"><em>sum</em></span> operation is not both associative and commutative, the
 				<span class="emphasis"><em>sum</em></span> expression is not well-formed,
 				which may result in unpredictable results during evaluation.
 				If an implementation is able to detect a lack of associativity or commutativity,
 				the implementation may bypass the evaluation and return an
 				<code class="code">invalid</code> result.
 			</p>
 <p>

 <code class="code">union(c : Collection(T)) : Bag(T)</code>

 </p>
 <p>The bag consisting of all elements in
 				<code class="code">self</code> and all elements in c.
 			</p>
 <p>

 <span class="bold"><strong>Iterations</strong></span>

 </p>
 <p>

 <code class="code">any(i : T[?] | body : Lambda T() : Boolean[1]) : T[?]</code>

 </p>
 <p>Returns any element in the
 				<span class="emphasis"><em>source</em></span> collection for which
 				<span class="emphasis"><em>body</em></span> evaluates to
 				<code class="code">true</code>.
 				Returns
 				<code class="code">invalid</code> if the
 				<span class="emphasis"><em>body</em></span> evaluates to
 				<code class="code">invalid</code> for any element,
 				otherwise if there are one or more elements for which the
 				<span class="emphasis"><em>body</em></span> is
 				<code class="code">true</code>,
 				an indeterminate choice of one of them is returned, otherwise the result is
 				<code class="code">invalid</code>.
 			</p>
 <p>let source : Collection(T) = ..., body : Lambda T() : Boolean = ... in
 				source-&gt;any(iterator | body) = source-&gt;select(iterator | body)
 				<span class="del">&gt;asSequence()</span>&gt;first()
 			</p>
 <p>

 <code class="code">collect(V)(i : T[?] | lambda : Lambda T() : V[?]) : Collection(V)</code>

 </p>
 <p>The Collection of elements that results from applying body to every member of the source set.
 				The result is flattened. Notice that this is based on collectNested, which can be of different type depending on the type of source.
 				collectNested is defined individually for each subclass of CollectionType.</p>
 <p>

 <code class="code">collectNested(V)(i : T[?] | lambda : Lambda T() : V[?]) : Collection(V)</code>

 </p>
 <p>The Collection of elements which results from applying body to every member of the source collection.</p>
 <p>

 <code class="code">exists(i : T[?] | lambda : Lambda T() : Boolean[?]) : Boolean[?]</code>

 </p>
 <p>Results in
 				<code class="code">true</code> if body evaluates to
 				<code class="code">true</code> for at least one element in the source collection.
 			</p>
 <p>

 <code class="code">exists(i : T[?], j : T[?] | lambda : Lambda T() : Boolean[?]) : Boolean[?]</code>

 </p>
 <p>

 <code class="code">forAll(i : T[?] | lambda : Lambda T() : Boolean[?]) : Boolean[?]</code>

 </p>
 <p>Results in
 				<code class="code">true</code> if the body expression evaluates to
 				<code class="code">true</code> for each element in the source collection; otherwise, result is
 				<code class="code">false</code>.
 			</p>
 <p>

 <code class="code">forAll(i : T[?], j : T[?] | lambda : Lambda T() : Boolean[?]) : Boolean[?]</code>

 </p>
 <p>

 <code class="code">isUnique(i : T[?] | lambda : Lambda T() : OclAny[?]) : Boolean[1]</code>

 </p>
 <p>Results in
 				<code class="code">true</code> if body evaluates to a different value for each element in the source collection; otherwise, result is
 				<code class="code">false</code>.
 			</p>
 <p>

 <code class="code">iterate(Tacc)(i : T[?]acc : ; Tacc[?] | lambda : Lambda T() : Tacc[?]) : Tacc[?]</code>

 </p>
 <p>

 <code class="code">one(i : T[?] | lambda : Lambda T() : Boolean[1]) : Boolean[1]</code>

 </p>
 <p>Results in
 				<code class="code">true</code> if there is exactly one element in the source collection for which body is
 				<code class="code">true</code>.
 			</p>
 <p>

 <code class="code">reject(i : T[?] | lambda : Lambda T() : Boolean[1]) : Collection(T)</code>

 </p>
 <p>The sub-collection of the source collection for which body is
 				<code class="code">false</code>.
 			</p>
 <p>

 <code class="code">select(i : T[?] | lambda : Lambda T() : Boolean[1]) : Collection(T)</code>

 </p>
 <p>The sub-collection of the source collection for which body is
 				<code class="code">true</code>.
 			</p>
 <p>

 <code class="code">sortedBy(i : T[?] | lambda : Lambda T() : OclAny[?]) : Sequence(T)</code>

 </p>
 <p>Results in the Collection containing all elements of the source collection.
 				The element for which body has the lowest value comes first, and so on.
 				The type of the body expression must have the &lt; operation defined.
 				The &lt; operation must return a Boolean value and must be transitive (i.e., if a &lt; b and b &lt; c then a &lt; c).</p>
 </div>
 <div class="section" title="Enumeration">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Enumeration"></a>
 				<span class="bold"><strong>
 					<code class="code">Enumeration</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>@Deprecated: Use OclEnumeration
 				The Enumeration type is the type of an OrderedSet of EnumerationLiteral.</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Attributes</strong></span>

 </p>
 <p>

 <code class="code">allLiterals : OrderedSet(EnumerationLiteral)</code>

 </p>
 <p>Evaluates to the literals of the enumeration.</p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">allInstances() : Set(OclSelf)</code>

 </p>
 <p>Return a set of all enumeration values of
 				<code class="code">self</code>.
 			</p>
 </div>
 <div class="section" title="EnumerationLiteral">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="EnumerationLiteral"></a>
 				<span class="bold"><strong>
 					<code class="code">EnumerationLiteral</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The standard type EnumerationLiteral represents a named constant value of an Enumeration.</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Attributes</strong></span>

 </p>
 <p>

 <code class="code">Enumeration : Bag(Enumeration[*|?])</code>

 </p>
 <p>

 <code class="code">OclEnumeration : Bag(OclEnumeration[*|?])</code>

 </p>
 </div>
 <div class="section" title="Integer">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Integer"></a>
 				<span class="bold"><strong>
 					<code class="code">Integer</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The standard type Integer represents the mathematical concept of integer.
 				Integer is itself an instance of the metatype PrimitiveType (from UML).</p>
 <p>conformsTo
 				<a class="link" href="#Real" title="Real">
 					<code class="code">Real</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">*(i : OclSelf[?]) : Integer[1]</code>
 				precedence:
 				<code class="code">MULTIPLICATIVE</code>

 </p>
 <p>The value of the multiplication of
 				<code class="code">self</code> and i.
 			</p>
 <p>

 <code class="code">+(i : OclSelf[?]) : Integer[1]</code>
 				precedence:
 				<code class="code">ADDITIVE</code>

 </p>
 <p>The value of the addition of
 				<code class="code">self</code> and i.
 			</p>
 <p>

 <code class="code">-() : Integer[1]</code>
 				precedence:
 				<code class="code">UNARY</code>

 </p>
 <p>The negative value of
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">-(i : OclSelf[?]) : Integer[1]</code>
 				precedence:
 				<code class="code">ADDITIVE</code>

 </p>
 <p>The value of the subtraction of i from
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">/(i : OclSelf[?]) : Real[1] invalidating</code>
 				precedence:
 				<code class="code">MULTIPLICATIVE</code>

 </p>
 <p>The value of
 				<code class="code">self</code> divided by i.
 				Evaluates to
 				<code class="code">invalid</code> if r is equal to zero.
 			</p>
 <p>

 <code class="code">abs() : Integer[1]</code>

 </p>
 <p>The absolute value of
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">div(i : Integer[?]) : Integer[1]</code>

 </p>
 <p>The number of times that i fits completely within
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">max(i : OclSelf[?]) : Integer[1]</code>

 </p>
 <p>The maximum of
 				<code class="code">self</code> an i.
 			</p>
 <p>

 <code class="code">min(i : OclSelf[?]) : Integer[1]</code>

 </p>
 <p>The minimum of
 				<code class="code">self</code> an i.
 			</p>
 <p>

 <code class="code">mod(i : Integer[?]) : Integer[1]</code>

 </p>
 <p>The result is
 				<code class="code">self</code> modulo i.
 			</p>
 <p>

 <code class="code">toString() : String[1]</code>

 </p>
 <p>Converts
 				<code class="code">self</code> to a string value.
 			</p>
 <p>

 <code class="code">toUnlimitedNatural() : UnlimitedNatural[1]</code>

 </p>
 <p>Converts a non-negative
 				<code class="code">self</code> to an UnlimitedNatural value. A negative
 				<code class="code">self</code> is converted to
 				<code class="code">invalid</code>.
 				An automatic coersion may be synthesized if the coercion enables an operation reference to be resolved
 				in an expression where no operation was available without coercion.
 			</p>
 </div>
 <div class="section" title="Map(K, V)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Map"></a>
 				<span class="bold"><strong>
 					<code class="code">Map(K, V)</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>A Map provides a Set of key values, each of which has an associated value.
 				Keys and values may be null, but neither may be invalid.</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Associations</strong></span>

 </p>
 <p>

 <code class="code">keyType : K[?]</code>

 </p>
 <p>The key type of the key-value pairs of
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">valueType : V[?]</code>

 </p>
 <p>The value type of the key-value pairs of
 				<code class="code">self</code>.
 			</p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>Evaluates to
 				<code class="code">true</code> if
 				<code class="code">self</code> and s contain the same elements.
 			</p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>

 <code class="code">at(key : OclAny[?]) : V[?] invalidating</code>

 </p>
 <p>The value of the map at
 				<code class="code">key</code>.
 			</p>
 <p>

 <code class="code">excludes(key : OclAny[?]) : Boolean[1]</code>

 </p>
 <p>True if
 				<code class="code">key</code> is not one of the keys of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">excludes(key : OclAny[?], value : OclAny[?]) : Boolean[1]</code>

 </p>
 <p>True if
 				<code class="code">key</code> and
 				<code class="code">value</code> are not a key-value pair of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">excludesAll(K2)(coll : Collection(K2)) : Boolean[1]</code>

 </p>
 <p>True if none of the elements of
 				<code class="code">coll</code> are keys of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">excludesMap(K2, V2)(map : Map(K2, V2)[?]) : Boolean[1]</code>

 </p>
 <p>True if none of the key-value pairs of
 				<code class="code">map</code> are also key-value pairs of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">excludesValue(value : OclAny[?]) : Boolean[1]</code>

 </p>
 <p>True if
 				<code class="code">value</code> is not one of the values of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">excluding(key : OclAny[?]) : Map(K, V)[?]</code>

 </p>
 <p>The map containing all key-value pairs of
 				<code class="code">self</code> except any whose key is
 				<code class="code">key</code>.
 			</p>
 <p>

 <code class="code">excluding(key : OclAny[?], value : OclAny[?]) : Map(K, V)[?]</code>

 </p>
 <p>The map containing all key-value pairs of
 				<code class="code">self</code> except any whose key is
 				<code class="code">key</code> and whose value is
 				<code class="code">key</code>.
 			</p>
 <p>

 <code class="code">excludingAll(keys : Collection(OclAny)) : Map(K, V)[?]</code>

 </p>
 <p>The map containing all key-value pairs of
 				<code class="code">self</code> except any whose key is included in
 				<code class="code">keys</code>.
 			</p>
 <p>

 <code class="code">excludingMap(K2, V2)(map : Map(K2, V2)[?]) : Map(K, V)[?]</code>

 </p>
 <p>The map containing all key-value pairs of
 				<code class="code">self</code> except any which is also included in
 				<code class="code">map</code>.
 			</p>
 <p>

 <code class="code">includes(key : OclAny[?]) : Boolean[1]</code>

 </p>
 <p>True if
 				<code class="code">key</code> is one of the keys of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">includes(key : OclAny[?], value : OclAny[?]) : Boolean[1]</code>

 </p>
 <p>True if
 				<code class="code">key</code> and
 				<code class="code">value</code> are a key-value pair of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">includesAll(K2)(coll : Collection(K2)) : Boolean[1]</code>

 </p>
 <p>True if all the elements of
 				<code class="code">coll</code> are keys of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">includesMap(K2, V2)(map : Map(K2, V2)[?]) : Boolean[1]</code>

 </p>
 <p>True if all of the key-value pairs of
 				<code class="code">map</code> are also key-value pairs of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">includesValue(value : OclAny[?]) : Boolean[1]</code>

 </p>
 <p>True if
 				<code class="code">value</code> is one of the values of
 				<code class="code">self</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">including(key : K[?], value : V[?]) : Map(K, V)[?]</code>

 </p>
 <p>The map containing all of the key-value pairs of
 				<code class="code">self</code> and an additional key-value pair for
 				<code class="code">key</code> and
 				<code class="code">value</code>.
 				If
 				<code class="code">key</code> is already a key of
 				<code class="code">self</code>, the old value pair is replaced by
 				<code class="code">value</code>.
 			</p>
 <p>

 <code class="code">includingMap(K2, V2)(map : Map(K2, V2)[?]) : Map(K, V)[?]</code>

 </p>
 <p>The map containing all of the key-value pairs of
 				<code class="code">self</code> and
 				<code class="code">map</code>.
 				The values associated with key-value pairs in
 				<code class="code">map</code> replace those in
 				<code class="code">self</code> where the same key is used by both maps.
 			</p>
 <p>

 <code class="code">isEmpty() : Boolean[1]</code>

 </p>
 <p>True if
 				<code class="code">self</code> is the empty map,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">keys() : Set(K)</code>

 </p>
 <p>A Set comprising all the keys of the key-value pairs in
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">notEmpty() : Boolean[1]</code>

 </p>
 <p>True if
 				<code class="code">self</code> not the empty map,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">size() : Integer[1]</code>

 </p>
 <p>The number of key-value pairs in
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">values() : Bag(V)</code>

 </p>
 <p>The Bag comprising all the values of the key-value pairs in
 				<code class="code">self</code>.
 			</p>
 </div>
 <div class="section" title="OclAny">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclAny"></a>
 				<span class="bold"><strong>
 					<code class="code">OclAny</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The number of elements in the collection
 				<code class="code">self</code>.essions.
 				OclAny is itself an instance of the metatype AnyType.
 			</p>
 <p>All classes in a UML model inherit all operations defined on OclAny.
 				To avoid name conflicts between properties in the model and the properties inherited from OclAny,
 				all names on the properties of OclAny start with &lsquo;ocl.&rsquo;
 				Although theoretically there may still be name conflicts, they can be avoided.
 				One can also use qualification by OclAny (name of the type) to explicitly refer to the OclAny properties.</p>
 <p>Operations of OclAny, where the instance of OclAny is called object.</p>
 <p>

 <span class="bold"><strong>Attributes</strong></span>

 </p>
 <p>

 <code class="code">OclInvalid : Bag(OclInvalid[*|?])</code>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>True if
 				<code class="code">self</code> is the same object as object2. Infix operator.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">post:&nbsp;result&nbsp;=&nbsp;self&nbsp;=&nbsp;object2<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>True if
 				<code class="code">self</code> is a different object from object2. Infix operator.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">post:&nbsp;result&nbsp;=&nbsp;not&nbsp;(self&nbsp;=&nbsp;object2)<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">oclAsSet() : Set(OclSelf)</code>

 </p>
 <p>Returns a Set with
 				<code class="code">self</code> as the sole content, unless
 				<code class="code">self</code> is
 				<code class="code">null</code> in which case returns an empty set,
 			</p>
 <p>

 <code class="code">oclAsType(TT)(type : TT[?]) : TT[1] invalidating</code>

 </p>
 <p>Evaluates to
 				<code class="code">self</code>, where
 				<code class="code">self</code> is of the type identified by
 				<code class="code">TT</code>.
 				The type
 				<code class="code">TT</code> may be any classifier defined by OCL or a user metamodel;
 				if the actual type of
 				<code class="code">self</code> at evaluation time does not conform to
 				<code class="code">TT</code>,
 				then the oclAsType operation evaluates to
 				<code class="code">invalid</code>.
 			</p>
 <p>If
 				<code class="code">self</code> is a multiply classified instance, the current classification used for OCL navigation
 				is changed to the classification to which
 				<code class="code">TT</code> conforms. The oclAsType call is not well-formed if
 				the classification is ambiguous.
 			</p>
 <p>In the case of feature redefinition, casting an object to a supertype of its actual type
 				does not access the supertype&rsquo;s definition of the feature;
 				according to the semantics of redefinition, the redefined feature simply does not exist for the object.
 				However, when casting to a supertype, any features additionally defined by the subtype are suppressed.</p>
 <div class="literallayout">
 <p>
 <code class="code">post&nbsp;IsSelf:&nbsp;result&nbsp;=&nbsp;self<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">oclIsInState(statespec : OclState[?]) : Boolean[1]</code>

 </p>
 <p>Evaluates to
 				<code class="code">true</code> if the
 				<code class="code">self</code> is in the state identified by statespec.
 			</p>
 <p>

 <code class="code">oclIsInvalid() : Boolean[1] validating</code>

 </p>
 <p>Evaluates to
 				<code class="code">true</code> if the
 				<code class="code">self</code> is equal to OclInvalid.
 			</p>
 <p>

 <code class="code">oclIsKindOf(type : OclType[?]) : Boolean[1]</code>

 </p>
 <p>Evaluates to
 				<code class="code">true</code> if the type of
 				<code class="code">self</code> conforms to
 				<code class="code">type</code>.
 				That is,
 				<code class="code">self</code> is of type
 				<code class="code">type</code> or a subtype of
 				<code class="code">type</code>.
 			</p>
 <p>

 <code class="code">oclIsNew() : Boolean[1]</code>

 </p>
 <p>Can only be used in a postcondition.
 				Evaluates to
 				<code class="code">true</code> if the
 				<code class="code">self</code> is created during performing the operation (for instance, it didn&rsquo;t exist at precondition time).
 			</p>
 <p>

 <code class="code">oclIsTypeOf(type : OclType[?]) : Boolean[1]</code>

 </p>
 <p>Evaluates to
 				<code class="code">true</code> if
 				<code class="code">self</code> is of the type
 				<code class="code">type</code> but not a subtype of
 				<code class="code">type</code>.
 			</p>
 <p>

 <code class="code">oclIsUndefined() : Boolean[1] validating</code>

 </p>
 <p>Evaluates to
 				<code class="code">true</code> if the
 				<code class="code">self</code> is equal to
 				<code class="code">invalid</code> or equal to
 				<code class="code">null</code>.
 			</p>
 <p>

 <code class="code">oclLog() : OclSelf[?]</code>

 </p>
 <p>Evaluates to the self, with the side effect of generating a log message comprising self.</p>
 <p>

 <code class="code">oclLog(message : String[?]) : OclSelf[?]</code>

 </p>
 <p>Evaluates to the self, with the side effect of generating a log message comprising message followed by self.</p>
 <p>

 <code class="code">oclType() : OclSelf[1]</code>

 </p>
 <p>Evaluates to the most derived type of which
 				<code class="code">self</code> is currently an instance. If
 				<code class="code">self</code> is an instance of a multiply
 				classified type, the return is the most derived type of the current classification which is established when the instance is
 				passed to OCL, or re-established by an
 				<code class="code">oclAsType()</code> call.
 			</p>
 <p>

 <code class="code">oclTypes() : Set(OclSelf[*|?])</code>

 </p>
 <p>Evaluates to all of the most derived type of which
 				<code class="code">self</code> is an instance. The return from
 				<code class="code">oclTypes()</code>
 				is normally equivalent to that from
 				<code class="code">oclType()</code> unless
 				<code class="code">self</code> is an instance of multiply classified type.
 			</p>
 <p>

 <code class="code">toString() : String[1]</code>

 </p>
 <p>Returns a string representation of
 				<code class="code">self</code>.
 			</p>
 </div>
 <div class="section" title="OclComparable">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclComparable"></a>
 				<span class="bold"><strong>
 					<code class="code">OclComparable</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The type OclComparable defines the compareTo operation used by the sortedBy iteration. Only types that provide a derived
 				compareTo implementation may be sorted.</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">&lt;(that : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">RELATIONAL</code>

 </p>
 <p>True if
 				<code class="code">self</code> is less than
 				<code class="code">that</code>.
 			</p>
 <p>

 <code class="code">&lt;=(that : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">RELATIONAL</code>

 </p>
 <p>True if
 				<code class="code">self</code> is less than or equal to
 				<code class="code">that</code>.
 			</p>
 <p>

 <code class="code">&gt;=(that : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">RELATIONAL</code>

 </p>
 <p>True if
 				<code class="code">self</code> is greater than or equal to
 				<code class="code">that</code>.
 			</p>
 <p>

 <code class="code">&gt;(that : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">RELATIONAL</code>

 </p>
 <p>True if
 				<code class="code">self</code> is greater than
 				<code class="code">that</code>.
 			</p>
 <p>

 <code class="code">compareTo(that : OclSelf[?]) : Integer[1]</code>

 </p>
 <p>Return -ve, 0, +ve according to whether self is less than, equal to , or greater than that.</p>
 <p>The compareTo operation should be commutative.</p>
 </div>
 <div class="section" title="OclElement">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclElement"></a>
 				<span class="bold"><strong>
 					<code class="code">OclElement</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The type OclElement is the implicit supertype of any user-defined type that has no explicit supertypes. Operations defined
 				for OclElement are therefore applicable to all user-defined types.</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Attributes</strong></span>

 </p>
 <p>

 <code class="code">OclElement : Bag(OclElement[*|?])</code>

 </p>
 <p>

 <code class="code">OclElement : Bag(OclElement[*|?])</code>

 </p>
 <p>

 <code class="code">oclContents : Set(OclElement)</code>

 </p>
 <p>The composed contents of self.</p>
 <p>

 <span class="bold"><strong>Associations</strong></span>

 </p>
 <p>

 <code class="code">oclContainer : OclElement[?]</code>

 </p>
 <p>The object for which self is a composed content or null if there is no such object.</p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">allInstances() : Set(OclSelf)</code>

 </p>
 <p>Return a set of all instances of the type and derived types of self.</p>
 <p>

 <code class="code">oclAsModelType(TT)(type : TT[?]) : TT[1] invalidating</code>

 </p>
 <p>Evaluates to
 				<code class="code">self</code>, where
 				<code class="code">self</code> is of the model type identified by
 				<code class="code">TT</code>.
 			</p>
 <p>Most model elements have metamodel types for use with oclAsType, but no model type and so the return is
 				<code class="code">invalid</code>.
 			</p>
 <p>Model elements such as UML&rsquo;s InstnaceSpecification that do support distinct model and metamodel types return
 				<code class="code">self</code>
 				with the cast type
 				<code class="code">TT</code> that may be used for further navigation.
 				If the actual model type of
 				<code class="code">self</code> at evaluation time does not conform to
 				<code class="code">TT</code>,
 				then the oclAsType operation evaluates to
 				<code class="code">invalid</code>.
 			</p>
 <p>If
 				<code class="code">self</code> is a multiply classified instance, the current classification used for OCL navigation
 				is changed to the classification to which
 				<code class="code">TT</code> conforms. The oclAsModelType call is not well-formed if
 				the classification is ambiguous.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">post&nbsp;IsSelf:&nbsp;result&nbsp;=&nbsp;self<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">oclContainer() : OclElement[?]</code>

 </p>
 <p>Returns the object for which self is a composed content or null if there is no such object.</p>
 <p>

 <code class="code">oclContents() : Set(OclElement)</code>

 </p>
 <p>Returns the composed contents of self.</p>
 <p>

 <code class="code">oclIsModelKindOf(type : OclType[?]) : Boolean[1]</code>

 </p>
 <p>Evaluates to
 				<code class="code">true</code> if the type of
 				<code class="code">self</code> conforms to the model type
 				<code class="code">type</code>.
 				That is,
 				<code class="code">self</code> is of type
 				<code class="code">type</code> or a subtype of
 				<code class="code">type</code>.
 			</p>
 <p>The return is normally
 				<code class="code">false</code> since few model elements have model types. UML&rsquo;s InstanceSpecification::classifier provides
 				a multiple classification for a model type.
 			</p>
 <p>

 <code class="code">oclModelType() : OclSelf[1]</code>

 </p>
 <p>Evaluates to the most derived model type of which
 				<code class="code">self</code> is currently an instance. If
 				<code class="code">self</code> is an instance of a multiply
 				classified model type, the return is the most derived type of the current classification which is established
 				by an
 				<code class="code">oclAsModelType()</code> call.
 			</p>
 <p>The return is normally
 				<code class="code">invalid</code> since few model elements have model types. UML&rsquo;s InstanceSpecification::classifier provides
 				a multiple classification for a model type.
 			</p>
 <p>

 <code class="code">oclModelTypes() : Set(OclSelf[*|?])</code>

 </p>
 <p>Evaluates to all of the most derived model types of which
 				<code class="code">self</code> is an instance. The return from
 				<code class="code">oclModelTypes()</code>
 				is normally equivalent to that from
 				<code class="code">oclModelType()</code> unless
 				<code class="code">self</code> is an instance of multiply classified model type.
 			</p>
 <p>The return is normally
 				<code class="code">invalid</code> since few model elements have model types. UML&rsquo;s InstanceSpecification::classifier provides
 				a multiple classification for a model type.
 			</p>
 </div>
 <div class="section" title="OclEnumeration">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclEnumeration"></a>
 				<span class="bold"><strong>
 					<code class="code">OclEnumeration</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The OclEnumeration type is the implicit supertype of any user Enumeration type.</p>
 <p>conformsTo
 				<a class="link" href="#OclType" title="OclType">
 					<code class="code">OclType</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Attributes</strong></span>

 </p>
 <p>

 <code class="code">allLiterals : OrderedSet(EnumerationLiteral)</code>

 </p>
 <p>Evaluates to the literals of the enumeration.</p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">allInstances() : Set(OclSelf)</code>

 </p>
 <p>Return a set of all enumeration values of
 				<code class="code">self</code>.
 			</p>
 </div>
 <div class="section" title="OclInvalid">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclInvalid"></a>
 				<span class="bold"><strong>
 					<code class="code">OclInvalid</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The type OclInvalid is a type that conforms to all other types.
 				It has one single instance, identified as
 				<code class="code">invalid</code>.
 				Any property call applied on invalid results in
 				<code class="code">invalid</code>, except for the operations oclIsUndefined() and oclIsInvalid().
 				OclInvalid is itself an instance of the metatype InvalidType.
 			</p>
 <p>conformsTo
 				<a class="link" href="#OclVoid" title="OclVoid">
 					<code class="code">OclVoid</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Associations</strong></span>

 </p>
 <p>

 <code class="code">oclBadProperty : OclAny[?]</code>

 </p>
 <p>An oclBadProperty may be used as a placeholder in an unsuccessfully created OCLExpression.</p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>Returns
 				<code class="code">invalid</code>.
 			</p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>Returns
 				<code class="code">invalid</code>.
 			</p>
 <p>

 <code class="code">allInstances() : Set(OclSelf)</code>

 </p>
 <p>Returns
 				<code class="code">invalid</code>.
 			</p>
 <p>

 <code class="code">and(b : Boolean[?]) : Boolean[?] validating</code>
 				precedence:
 				<code class="code">AND</code>

 </p>
 <p>

 <code class="code">implies(b : Boolean[?]) : Boolean[?] validating</code>
 				precedence:
 				<code class="code">IMPLIES</code>

 </p>
 <p>

 <code class="code">oclAsSet() : Set(OclSelf)</code>

 </p>
 <p>

 <code class="code">oclAsType(TT)(type : TT[?]) : TT[?]</code>

 </p>
 <p>

 <code class="code">oclBadOperation() : OclAny[?]</code>

 </p>
 <p>An oclBadOperation may be used as a placeholder in an unsuccessfully created OCLExpression.</p>
 <p>

 <code class="code">oclIsInvalid() : Boolean[1] validating</code>

 </p>
 <p>

 <code class="code">oclIsKindOf(type : OclType[?]) : Boolean[1]</code>

 </p>
 <p>

 <code class="code">oclIsTypeOf(type : OclType[?]) : Boolean[1]</code>

 </p>
 <p>

 <code class="code">oclIsUndefined() : Boolean[1] validating</code>

 </p>
 <p>

 <code class="code">oclType() : OclSelf[1]</code>

 </p>
 <p>

 <code class="code">or(b : Boolean[?]) : Boolean[?] validating</code>
 				precedence:
 				<code class="code">OR</code>

 </p>
 <p>

 <code class="code">toString() : String[1]</code>

 </p>
 <p>Returns &lsquo;invalid&rsquo;.</p>
 </div>
 <div class="section" title="OclLambda">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclLambda"></a>
 				<span class="bold"><strong>
 					<code class="code">OclLambda</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The type OclLambda is the implicit supertype of all Lambda types. The operations defined for OclLambda
 				therefore apply to all lambda expressions.</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 </div>
 <div class="section" title="OclMessage">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclMessage"></a>
 				<span class="bold"><strong>
 					<code class="code">OclMessage</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>OclMessage
 				This sub clause contains the definition of the standard type OclMessage.
 				As defined in this sub clause, each ocl message type is actually a template type with one parameter.
 				&lsquo;T&rsquo; denotes the parameter.
 				A concrete ocl message type is created by substituting an operation or signal for the T.</p>
 <p>The predefined type OclMessage is an instance of MessageType.
 				Every OclMessage is fully determined by either the operation, or signal given as parameter.
 				Note that there is conceptually an undefined (infinite) number of these types,
 				as each is determined by a different operation or signal.
 				These types are unnamed. Every type has as attributes the name of the operation or signal,
 				and either all formal parameters of the operation, or all attributes of the signal.
 				OclMessage is itself an instance of the metatype MessageType.</p>
 <p>OclMessage has a number of predefined operations, as shown in the OCL Standard Library.</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">hasReturned() : Boolean[1]</code>

 </p>
 <p>True if type of template parameter is an operation call, and the called operation has returned a value.
 				This implies the fact that the message has been sent. False in all other cases.</p>
 <p>

 <code class="code">isOperationCall() : Boolean[1]</code>

 </p>
 <p>Returns
 				<code class="code">true</code> if the OclMessage represents the sending of a UML Operation call.
 			</p>
 <p>

 <code class="code">isSignalSent() : Boolean[1]</code>

 </p>
 <p>Returns
 				<code class="code">true</code> if the OclMessage represents the sending of a UML Signal.
 			</p>
 <p>

 <code class="code">result() : OclAny[?]</code>

 </p>
 <p>Returns the result of the called operation, if type of template parameter is an operation call,
 				and the called operation has returned a value. Otherwise the
 				<code class="code">invalid</code> value is returned.
 			</p>
 </div>
 <div class="section" title="OclSelf">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclSelf"></a>
 				<span class="bold"><strong>
 					<code class="code">OclSelf</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The pseudo-type OclSelf denotes the statically determinate type of
 				<code class="code">self</code> in Operation
 				and Iteration signatures. Instances of OclSelf are never created.
 			</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 </div>
 <div class="section" title="OclState">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclState"></a>
 				<span class="bold"><strong>
 					<code class="code">OclState</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 </div>
 <div class="section" title="OclStereotype">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclStereotype"></a>
 				<span class="bold"><strong>
 					<code class="code">OclStereotype</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The type OclStereotype is the implicit supertype of any UML stereotype. Operations defined
 				for OclStereotype are therefore applicable to all UML stereotypes.</p>
 <p>conformsTo
 				<a class="link" href="#OclType" title="OclType">
 					<code class="code">OclType</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">allInstances() : Set(OclSelf)</code>

 </p>
 <p>Return a set of all instances of the stereotype and derived types of self.</p>
 </div>
 <div class="section" title="OclSummable">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclSummable"></a>
 				<span class="bold"><strong>
 					<code class="code">OclSummable</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The type OclSummable defines the sum and zero operations used by the Collection::sum iteration. Only types that provide derived
 				sum and zero implementations may be summed.</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">sum(that : OclSelf[?]) : OclSelf[?]</code>

 </p>
 <p>Return the sum of self and that.</p>
 <p>The sum operation should be associative.</p>
 <p>

 <code class="code">zero() : OclSelf[?]</code>

 </p>
 <p>Return the &lsquo;zero&rsquo; value of self to initialize a summation.</p>
 <p>zero().sum(self) = self.</p>
 </div>
 <div class="section" title="OclTuple">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclTuple"></a>
 				<span class="bold"><strong>
 					<code class="code">OclTuple</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The type OclTuple is the implicit supertype of all Tuple types. The operations defined for OclTuple
 				therefore apply to all tuples.</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 </div>
 <div class="section" title="OclType">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclType"></a>
 				<span class="bold"><strong>
 					<code class="code">OclType</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The type OclType is the implicit supertype of any UML type. Operations defined
 				for OclType are therefore applicable to all UML types.</p>
 <p>conformsTo
 				<a class="link" href="#OclElement" title="OclElement">
 					<code class="code">OclElement</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">conformsTo(type2 : OclType[?]) : Boolean[1]</code>

 </p>
 <p>Returns true if type2 conforms to self.</p>
 </div>
 <div class="section" title="OclVoid">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OclVoid"></a>
 				<span class="bold"><strong>
 					<code class="code">OclVoid</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The type OclVoid is a type that conforms to all other types except OclInvalid.
 				It has one single instance, identified as
 				<code class="code">null</code>, that corresponds with the UML LiteralNull value specification.
 				Any property call applied on
 				<code class="code">null</code> results in
 				<code class="code">invalid</code>, except for the
 				oclIsUndefined(), oclIsInvalid(), =(OclAny) and &lt;&gt;(OclAny) operations.
 				However, by virtue of the implicit conversion to a collection literal,
 				an expression evaluating to
 				<code class="code">null</code> can be used as source of collection operations (such as &lsquo;isEmpty&rsquo;).
 				If the source is the
 				<code class="code">null</code> literal, it is implicitly converted to Bag{}.
 			</p>
 <p>OclVoid is itself an instance of the metatype VoidType.</p>
 <p>conformsTo
 				<a class="link" href="#OclAny" title="OclAny">
 					<code class="code">OclAny</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>Redefines the OclAny operation, returning
 				<code class="code">true</code> if object is
 				<code class="code">null</code>,
 				<code class="code">invalid</code>
 				if object is
 				<code class="code">invalid</code>,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>

 <code class="code">allInstances() : Set(OclSelf[*|?])</code>

 </p>
 <p>Returns
 				<code class="code">Set{null}</code>.
 			</p>
 <p>

 <code class="code">and(b : Boolean[?]) : Boolean[?]</code>
 				precedence:
 				<code class="code">AND</code>

 </p>
 <p>

 <code class="code">implies(b : Boolean[?]) : Boolean[?]</code>
 				precedence:
 				<code class="code">IMPLIES</code>

 </p>
 <p>

 <code class="code">oclAsSet() : Set(OclSelf)</code>

 </p>
 <p>

 <code class="code">oclIsInvalid() : Boolean[1] validating</code>

 </p>
 <p>

 <code class="code">oclIsUndefined() : Boolean[1] validating</code>

 </p>
 <p>

 <code class="code">or(b : Boolean[?]) : Boolean[?]</code>
 				precedence:
 				<code class="code">OR</code>

 </p>
 <p>

 <code class="code">toString() : String[1]</code>

 </p>
 <p>Returns
 				<code class="code">null</code>.
 			</p>
 </div>
 <div class="section" title="OrderedCollection(T)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OrderedCollection"></a>
 				<span class="bold"><strong>
 					<code class="code">OrderedCollection(T)</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The OrderedCollection type provides the shared functionality of the OrderedSet and Sequence
 				collections for which the elements are ordered.
 				The common supertype of OrderedCollection is Collection.</p>
 <p>conformsTo
 				<a class="link" href="#Collection" title="Collection(T)">
 					<code class="code">Collection(T)</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">at(index : Integer[?]) : T[?] invalidating</code>

 </p>
 <p>The i-th element of ordered collection.</p>
 <p>

 <code class="code">first() : T[?] invalidating</code>

 </p>
 <p>The first element in
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">indexOf(obj : OclAny[?]) : Integer[1] invalidating</code>

 </p>
 <p>The index of object obj in the ordered collection.</p>
 <p>

 <code class="code">last() : T[?] invalidating</code>

 </p>
 <p>The last element in
 				<code class="code">self</code>.
 			</p>
 </div>
 <div class="section" title="OrderedSet(T)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OrderedSet"></a>
 				<span class="bold"><strong>
 					<code class="code">OrderedSet(T)</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The OrderedSet is a Set, the elements of which are ordered.
 				It contains no duplicates. OrderedSet is itself an instance of the metatype OrderedSetType.
 				An OrderedSet is not a subtype of Set, neither a subtype of Sequence.
 				The common supertype of Sets and OrderedSets is Collection.</p>
 <p>conformsTo
 				<a class="link" href="#OrderedCollection" title="OrderedCollection(T)">
 					<code class="code">OrderedCollection(T)</code>
 				</a>,
 				<a class="link" href="#UniqueCollection" title="UniqueCollection(T)">
 					<code class="code">UniqueCollection(T)</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>

 <code class="code">-(s : UniqueCollection(OclAny)) : OrderedSet(T)</code>
 				precedence:
 				<code class="code">ADDITIVE</code>

 </p>
 <p>The elements of
 				<code class="code">self</code>, which are not in s.
 			</p>
 <p>

 <code class="code">append(object : T[?]) : OrderedSet(T)</code>

 </p>
 <p>The set of elements, consisting of all elements of
 				<code class="code">self</code>, followed by object.
 			</p>
 <p>

 <code class="code">appendAll(objects : OrderedCollection(T)) : OrderedSet(T)</code>

 </p>
 <p>The set of elements, consisting of all elements of
 				<code class="code">self</code>, followed by objects.
 			</p>
 <p>

 <code class="code">excluding(object : OclAny[?]) : OrderedSet(T)</code>

 </p>
 <p>The ordered set  containing all elements of
 				<code class="code">self</code> apart from object.
 			</p>
 <p>The order of the remaining elements is not changed.</p>
 <p>

 <code class="code">excludingAll(objects : Collection(OclAny)) : OrderedSet(T)</code>

 </p>
 <p>The ordered set containing all elements of
 				<code class="code">self</code> apart from all occurrences of all objects.
 			</p>
 <p>

 <code class="code">flatten(T2)() : OrderedSet(T2)</code>

 </p>
 <p>

 <code class="code">including(object : T[?]) : OrderedSet(T)</code>

 </p>
 <p>The ordered set containing all elements of
 				<code class="code">self</code> plus object added as the last element if not already present.
 			</p>
 <p>

 <code class="code">includingAll(objects : Collection(T)) : OrderedSet(T)</code>

 </p>
 <p>The ordered set containing all elements of
 				<code class="code">self</code> plus objects added as the last elements.
 			</p>
 <p>

 <code class="code">insertAt(index : Integer[?], object : T[?]) : OrderedSet(T) invalidating</code>

 </p>
 <p>The ordered set consisting of
 				<code class="code">self</code> with object present at position index.
 			</p>
 <p>

 <code class="code">prepend(object : T[?]) : OrderedSet(T)</code>

 </p>
 <p>The sequence consisting of object, followed by all elements in
 				<code class="code">self</code>.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">post&nbsp;IsAtStart:&nbsp;result-&gt;at(1)&nbsp;=&nbsp;object<br>

 </code>
 </p>
 </div>
 <p></p>
 <div class="literallayout">
 <p>
 <code class="code">post&nbsp;IsShiftedAlong:&nbsp;Sequence{1..self-&gt;size()}-&gt;forAll(index&nbsp;|&nbsp;self-&gt;at(index)&nbsp;=&nbsp;result-&gt;at(index&nbsp;+&nbsp;1))<br>

 </code>
 </p>
 </div>
 <p></p>
 <div class="literallayout">
 <p>
 <code class="code">post&nbsp;IsSizePlusOne:&nbsp;result-&gt;size()&nbsp;=&nbsp;self-&gt;size()&nbsp;+&nbsp;1<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">prependAll(objects : OrderedCollection(T)) : OrderedSet(T)</code>

 </p>
 <p>The sequence consisting of objects, followed by all elements in
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">reverse() : OrderedSet(T)</code>

 </p>
 <p>The ordered set of elements with same elements but with the opposite order.</p>
 <p>

 <code class="code">selectByKind(TT)(type : TT[?]) : OrderedSet(TT)</code>

 </p>
 <p>

 <code class="code">selectByType(TT)(type : TT[?]) : OrderedSet(TT)</code>

 </p>
 <p>

 <code class="code">subOrderedSet(lower : Integer[?], upper : Integer[?]) : OrderedSet(T) invalidating</code>

 </p>
 <p>The sub-set of
 				<code class="code">self</code> starting at number lower, up to and including element number upper.
 			</p>
 <p>

 <span class="bold"><strong>Iterations</strong></span>

 </p>
 <p>

 <code class="code">closure(i : T[1] | lambda : Lambda T() : OrderedSet(T)[?]) : OrderedSet(T)</code>

 </p>
 <p>The closure of applying body transitively to every distinct element of the source collection.</p>
 <p>

 <code class="code">collect(V)(i : T[?] | lambda : Lambda T() : V[?]) : Sequence(V)</code>

 </p>
 <p>

 <code class="code">collectNested(V)(i : T[?] | lambda : Lambda T() : V[?]) : Sequence(V)</code>

 </p>
 <p>The sequence of elements that results from applying body to every member of the source ordered collection.</p>
 <p>

 <code class="code">reject(i : T[?] | lambda : Lambda T() : Boolean[1]) : OrderedSet(T)</code>

 </p>
 <p>The ordered set of the source ordered set for which body is
 				<code class="code">false</code>.
 			</p>
 <p>

 <code class="code">select(i : T[?] | lambda : Lambda T() : Boolean[1]) : OrderedSet(T)</code>

 </p>
 <p>The ordered set of the source ordered set for which body is
 				<code class="code">true</code>

 </p>
 <p>

 <code class="code">sortedBy(i : T[?] | lambda : Lambda T() : OclAny[?]) : OrderedSet(T)</code>

 </p>
 <p>Results in the ordered set containing all elements of the source collection.
 				The element for which body has the lowest value comes first, and so on.
 				The type of the body expression must have the &lt; operation defined.
 				The &lt; operation must return a Boolean value and must be transitive (i.e., if a &lt; b and b &lt; c, then a &lt; c).</p>
 </div>
 <div class="section" title="Real">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Real"></a>
 				<span class="bold"><strong>
 					<code class="code">Real</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The standard type Real represents the mathematical concept of real.
 				Note that Integer is a subclass of Real,
 				so for each parameter of type Real, you can use an integer as the actual parameter.
 				Real is itself an instance of the metatype PrimitiveType (from UML).</p>
 <p>conformsTo
 				<a class="link" href="#OclComparable" title="OclComparable">
 					<code class="code">OclComparable</code>
 				</a>,
 				<a class="link" href="#OclSummable" title="OclSummable">
 					<code class="code">OclSummable</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>Returns
 				<code class="code">true</code> if the numeric value of
 				<code class="code">self</code> is the same as the numeric value of object2,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>Returns
 				<code class="code">true</code> if the numeric value of
 				<code class="code">self</code> is the not the same as the numeric value of object2,
 				<code class="code">false</code> otherwise.
 			</p>
 <p>

 <code class="code">*(r : OclSelf[?]) : Real[1]</code>
 				precedence:
 				<code class="code">MULTIPLICATIVE</code>

 </p>
 <p>The value of the multiplication of
 				<code class="code">self</code> and r.
 			</p>
 <p>

 <code class="code">+(r : OclSelf[?]) : Real[1]</code>
 				precedence:
 				<code class="code">ADDITIVE</code>

 </p>
 <p>The value of the addition of
 				<code class="code">self</code> and r.
 			</p>
 <p>

 <code class="code">-() : Real[1]</code>
 				precedence:
 				<code class="code">UNARY</code>

 </p>
 <p>The negative value of
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">-(r : OclSelf[?]) : Real[1]</code>
 				precedence:
 				<code class="code">ADDITIVE</code>

 </p>
 <p>The value of the subtraction of r from
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">/(r : OclSelf[?]) : Real[1] invalidating</code>
 				precedence:
 				<code class="code">MULTIPLICATIVE</code>

 </p>
 <p>The value of
 				<code class="code">self</code> divided by r. Evaluates to
 				<code class="code">invalid</code> if r is equal to zero.
 			</p>
 <p>

 <code class="code">abs() : Real[1]</code>

 </p>
 <p>The absolute value of
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">floor() : Integer[1]</code>

 </p>
 <p>The largest integer that is less than or equal to
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">max(r : OclSelf[?]) : Real[1]</code>

 </p>
 <p>The maximum of
 				<code class="code">self</code> and r.
 			</p>
 <p>

 <code class="code">min(r : OclSelf[?]) : Real[1]</code>

 </p>
 <p>The minimum of
 				<code class="code">self</code> and r.
 			</p>
 <p>

 <code class="code">round() : Integer[1]</code>

 </p>
 <p>The integer that is closest to
 				<code class="code">self</code>. When there are two such integers, the largest one.
 			</p>
 <p>

 <code class="code">toString() : String[1]</code>

 </p>
 <p>Converts
 				<code class="code">self</code> to a string value.
 			</p>
 </div>
 <div class="section" title="Sequence(T)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Sequence"></a>
 				<span class="bold"><strong>
 					<code class="code">Sequence(T)</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>A sequence is a collection where the elements are ordered.
 				An element may be part of a sequence more than once.
 				Sequence is itself an instance of the metatype SequenceType.
 				A Sentence is not a subtype of Bag.
 				The common supertype of Sentence and Bags is Collection.</p>
 <p>conformsTo
 				<a class="link" href="#OrderedCollection" title="OrderedCollection(T)">
 					<code class="code">OrderedCollection(T)</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>True if
 				<code class="code">self</code> contains the same elements as s in the same order.
 			</p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>

 <code class="code">append(object : T[?]) : Sequence(T)</code>

 </p>
 <p>The sequence of elements, consisting of all elements of
 				<code class="code">self</code>, followed by object.
 			</p>
 <p>

 <code class="code">appendAll(objects : OrderedCollection(T)) : Sequence(T)</code>

 </p>
 <p>The sequence of elements, consisting of all elements of
 				<code class="code">self</code>, followed by objects.
 			</p>
 <p>

 <code class="code">excluding(object : OclAny[?]) : Sequence(T)</code>

 </p>
 <p>The sequence containing all elements of
 				<code class="code">self</code> apart from all occurrences of object.
 			</p>
 <p>The order of the remaining elements is not changed.</p>
 <p>

 <code class="code">excludingAll(objects : Collection(OclAny)) : Sequence(T)</code>

 </p>
 <p>The sequence containing all elements of
 				<code class="code">self</code> apart from all occurrences of all objects.
 			</p>
 <p>

 <code class="code">flatten(T2)() : Sequence(T2)</code>

 </p>
 <p>Redefines the Collection operation. If the element type is not a collection type, this results in the same sequence as
 				<code class="code">self</code>.
 				If the element type is a collection type, the result is the sequence containing all the elements
 				of all the recursively flattened elements of
 				<code class="code">self</code>. The order of the elements is partial.
 			</p>
 <p>

 <code class="code">including(object : T[?]) : Sequence(T)</code>

 </p>
 <p>The sequence containing all elements of
 				<code class="code">self</code> plus object added as the last element.
 			</p>
 <p>

 <code class="code">includingAll(objects : Collection(T)) : Sequence(T)</code>

 </p>
 <p>The sequence containing all elements of
 				<code class="code">self</code> plus objects added as the last elements.
 			</p>
 <p>

 <code class="code">insertAt(index : Integer[?], object : T[?]) : Sequence(T) invalidating</code>

 </p>
 <p>The sequence consisting of
 				<code class="code">self</code> with object inserted at position index.
 			</p>
 <p>

 <code class="code">prepend(object : T[?]) : Sequence(T)</code>

 </p>
 <p>The sequence consisting of object, followed by all elements in
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">prependAll(objects : OrderedCollection(T)) : Sequence(T)</code>

 </p>
 <p>The sequence consisting of objects, followed by all elements in
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">reverse() : Sequence(T)</code>

 </p>
 <p>The sequence containing the same elements but with the opposite order.</p>
 <p>

 <code class="code">selectByKind(TT)(type : TT[?]) : Sequence(TT)</code>

 </p>
 <p>

 <code class="code">selectByType(TT)(type : TT[?]) : Sequence(TT)</code>

 </p>
 <p>

 <code class="code">subSequence(lower : Integer[?], upper : Integer[?]) : Sequence(T) invalidating</code>

 </p>
 <p>The sub-sequence of
 				<code class="code">self</code> starting at number lower, up to and including element number upper.
 			</p>
 <p>

 <span class="bold"><strong>Iterations</strong></span>

 </p>
 <p>

 <code class="code">closure(i : T[1] | lambda : Lambda T() : OrderedSet(T)[?]) : OrderedSet(T)</code>

 </p>
 <p>The closure of applying body transitively to every distinct element of the source collection.</p>
 <p>

 <code class="code">collect(V)(i : T[?] | lambda : Lambda T() : V[?]) : Sequence(V)</code>

 </p>
 <p>

 <code class="code">collectNested(V)(i : T[?] | lambda : Lambda T() : V[?]) : Sequence(V)</code>

 </p>
 <p>The sequence of elements that results from applying body to every member of the source ordered collection.</p>
 <p>

 <code class="code">reject(i : T[?] | lambda : Lambda T() : Boolean[1]) : Sequence(T)</code>

 </p>
 <p>The subsequence of the source sequence for which body is
 				<code class="code">false</code>.
 			</p>
 <p>

 <code class="code">select(i : T[?] | lambda : Lambda T() : Boolean[1]) : Sequence(T)</code>

 </p>
 <p>The subsequence of the source sequence for which body is
 				<code class="code">true</code>.
 			</p>
 <p>

 <code class="code">sortedBy(i : T[?] | lambda : Lambda T() : OclAny[?]) : Sequence(T)</code>

 </p>
 <p>Results in the Sequence containing all elements of the source collection.
 				The element for which body has the lowest value comes first, and so on.
 				The type of the body expression must have the &lt; operation defined.
 				The &lt; operation must return a Boolean value and must be transitive (i.e., if a &lt; b and b &lt; c then a &lt; c).</p>
 </div>
 <div class="section" title="Set(T)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Set"></a>
 				<span class="bold"><strong>
 					<code class="code">Set(T)</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>conformsTo
 				<a class="link" href="#UniqueCollection" title="UniqueCollection(T)">
 					<code class="code">UniqueCollection(T)</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>Evaluates to
 				<code class="code">true</code> if
 				<code class="code">self</code> and s contain the same elements.
 			</p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>

 <code class="code">-(s : UniqueCollection(OclAny)) : Set(T)</code>
 				precedence:
 				<code class="code">ADDITIVE</code>

 </p>
 <p>The elements of
 				<code class="code">self</code>, which are not in s.
 			</p>
 <p>

 <code class="code">excluding(object : OclAny[?]) : Set(T)</code>

 </p>
 <p>The set containing all elements of
 				<code class="code">self</code> without object.
 			</p>
 <p>

 <code class="code">excludingAll(objects : Collection(OclAny)) : Set(T)</code>

 </p>
 <p>The set containing all elements of
 				<code class="code">self</code> apart from all occurrences of all objects.
 			</p>
 <p>

 <code class="code">flatten(T2)() : Set(T2)</code>

 </p>
 <p>Redefines the Collection operation. If the element type is not a collection type, this results in the same set as
 				<code class="code">self</code>.
 				If the element type is a collection type, the result is the set containing all the elements of all the recursively flattened elements of
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">including(object : T[?]) : Set(T)</code>

 </p>
 <p>The set containing all elements of
 				<code class="code">self</code> plus object.
 			</p>
 <p>

 <code class="code">includingAll(objects : Collection(T)) : Set(T)</code>

 </p>
 <p>The set containing all elements of
 				<code class="code">self</code> and objects.
 			</p>
 <p>

 <code class="code">selectByKind(TT)(type : TT[?]) : Set(TT)</code>

 </p>
 <p>

 <code class="code">selectByType(TT)(type : TT[?]) : Set(TT)</code>

 </p>
 <p>

 <span class="bold"><strong>Iterations</strong></span>

 </p>
 <p>

 <code class="code">closure(i : T[1] | lambda : Lambda T() : Set(T)[?]) : Set(T)</code>

 </p>
 <p>The closure of applying body transitively to every distinct element of the source collection.</p>
 <p>

 <code class="code">collect(V)(i : T[?] | lambda : Lambda T() : V[?]) : Bag(V)</code>

 </p>
 <p>

 <code class="code">collectNested(V)(i : T[?] | lambda : Lambda T() : V[?]) : Bag(V)</code>

 </p>
 <p>The Bag of elements which results from applying body to every member of the source nonordered collection.</p>
 <p>

 <code class="code">reject(i : T[?] | lambda : Lambda T() : Boolean[1]) : Set(T)</code>

 </p>
 <p>The subset of the source set for which body is
 				<code class="code">false</code>.
 			</p>
 <p>

 <code class="code">select(i : T[?] | lambda : Lambda T() : Boolean[1]) : Set(T)</code>

 </p>
 <p>The subset of set for which expr is
 				<code class="code">true</code>.
 			</p>
 <p>

 <code class="code">sortedBy(i : T[?] | lambda : Lambda T() : OclAny[?]) : OrderedSet(T)</code>

 </p>
 <p>Results in the ordered set containing all elements of the source collection.
 				The element for which body has the lowest value comes first, and so on.
 				The type of the body expression must have the &lt; operation defined.
 				The &lt; operation must return a Boolean value and must be transitive (i.e., if a &lt; b and b &lt; c, then a &lt; c).</p>
 </div>
 <div class="section" title="State">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="State"></a>
 				<span class="bold"><strong>
 					<code class="code">State</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>conformsTo
 				<a class="link" href="#OclState" title="OclState">
 					<code class="code">OclState</code>
 				</a>

 </p>
 </div>
 <div class="section" title="String">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="String"></a>
 				<span class="bold"><strong>
 					<code class="code">String</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The standard type String represents strings, which can be both ASCII or Unicode.
 				String is itself an instance of the metatype PrimitiveType (from UML).</p>
 <p>conformsTo
 				<a class="link" href="#OclComparable" title="OclComparable">
 					<code class="code">OclComparable</code>
 				</a>,
 				<a class="link" href="#OclSummable" title="OclSummable">
 					<code class="code">OclSummable</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">=(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>

 <code class="code">&lt;&gt;(object2 : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">EQUALITY</code>

 </p>
 <p>

 <code class="code">&lt;(s : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">RELATIONAL</code>

 </p>
 <p>True if
 				<code class="code">self</code> is less than s, using the locale defined by looking up oclLocale in the current environment.
 			</p>
 <p>

 <code class="code">&lt;=(s : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">RELATIONAL</code>

 </p>
 <p>True if
 				<code class="code">self</code> is less than or equal to s, using the locale defined by looking up oclLocale in the current environment.
 			</p>
 <p>

 <code class="code">&gt;=(s : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">RELATIONAL</code>

 </p>
 <p>True if
 				<code class="code">self</code> is greater than or equal to s, using the locale defined by looking up oclLocale in the current environment.
 			</p>
 <p>

 <code class="code">&gt;(s : OclSelf[?]) : Boolean[1]</code>
 				precedence:
 				<code class="code">RELATIONAL</code>

 </p>
 <p>True if
 				<code class="code">self</code> is greater than s, using the locale defined by looking up oclLocale in the current environment.
 			</p>
 <p>

 <code class="code">+(s : String[?]) : String[1]</code>
 				precedence:
 				<code class="code">ADDITIVE</code>

 </p>
 <p>The concatenation of
 				<code class="code">self</code> and s.
 			</p>
 <p>

 <code class="code">at(i : Integer[?]) : String[1] invalidating</code>

 </p>
 <p>Queries the character at position i in
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">characters() : Sequence(String)</code>

 </p>
 <p>Obtains the characters of
 				<code class="code">self</code> as a sequence.
 			</p>
 <p>

 <code class="code">compareTo(that : OclSelf[?]) : Integer[1]</code>

 </p>
 <p>The comparison of
 				<code class="code">self</code> with
 				<code class="code">that</code>. -ve if less than, 0 if equal, +ve if greater than.
 			</p>
 <p>

 <code class="code">concat(s : String[?]) : String[1]</code>

 </p>
 <p>The concatenation of
 				<code class="code">self</code> and s.
 			</p>
 <p>

 <code class="code">endsWith(s : String[?]) : Boolean[1]</code>

 </p>
 <p>Returns true if
 				<code class="code">self</code> ends with the string s.
 				Every string ends with the empty string.
 			</p>
 <p>

 <code class="code">equalsIgnoreCase(s : String[?]) : Boolean[1]</code>

 </p>
 <p>Queries whether s and
 				<code class="code">self</code> are equivalent under case-insensitive collation.
 			</p>
 <p>

 <code class="code">indexOf(s : String[?]) : Integer[1]</code>

 </p>
 <p>Queries the first index in
 				<code class="code">self</code> at which s is a substring of
 				<code class="code">self</code>, or zero if s is not a substring of
 				<code class="code">self</code>.
 				The empty string is a substring of every string at index 1 (and also at all other indexes).
 			</p>
 <p>

 <code class="code">lastIndexOf(s : String[?]) : Integer[1]</code>

 </p>
 <p>Queries the last in
 				<code class="code">self</code> at which s is a substring of
 				<code class="code">self</code>, or zero if s is not a substring of
 				<code class="code">self</code>.
 				The empty string is a substring of every string at index
 				<code class="code">self</code>-size()+1 (and also at all other indexes).
 			</p>
 <p>

 <code class="code">matches(regex : String[?]) : Boolean[1]</code>

 </p>
 <p>Use a regular expression match and return true if self matches regex, false otherwise.</p>
 <p>

 <code class="code">replaceAll(regex : String[?], replacement : String[?]) : String[1] invalidating</code>

 </p>
 <p>Return a string derived from self by replacing all matches of regex by replacement.</p>
 <p>

 <code class="code">replaceFirst(regex : String[?], replacement : String[?]) : String[1] invalidating</code>

 </p>
 <p>Return a string derived from self by replacing the first match of regex by replacement.</p>
 <p>

 <code class="code">size() : Integer[1]</code>

 </p>
 <p>The number of characters in
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">startsWith(s : String[?]) : Boolean[1]</code>

 </p>
 <p>Returns true if
 				<code class="code">self</code> starts with the string s.
 				Every string starts with the empty string.
 			</p>
 <p>

 <code class="code">substituteAll(oldSubstring : String[?], newSubstring : String[?]) : String[1]</code>

 </p>
 <p>Return a string derived from self by replacing all occurrences of oldSubstring by newSubstring.</p>
 <p>

 <code class="code">substituteFirst(oldSubstring : String[?], newSubstring : String[?]) : String[1]</code>

 </p>
 <p>Return a string derived from self by replacing the first occurrence of oldSubstring by newSubstring.
 				Returns invalid if there is no first occurrence.</p>
 <p>

 <code class="code">substring(lower : Integer[?], upper : Integer[?]) : String[1] invalidating</code>

 </p>
 <p>The sub-string of
 				<code class="code">self</code> starting at character number lower, up to and including character number upper. Character numbers run from 1 to self.size().
 			</p>
 <p>

 <code class="code">toBoolean() : Boolean[1] invalidating</code>

 </p>
 <p>Converts
 				<code class="code">self</code> to a boolean value.
 			</p>
 <p>

 <code class="code">toInteger() : Integer[1] invalidating</code>

 </p>
 <p>Converts
 				<code class="code">self</code> to an Integer value.
 			</p>
 <p>

 <code class="code">toLower() : String[1]</code>

 </p>
 <p>This is a deprecated variant of toLowerCase() preserving compatibility with traditional Eclipse OCL behaviour.</p>
 <p>

 <code class="code">toLowerCase() : String[1]</code>

 </p>
 <p>Converts
 				<code class="code">self</code> to lower case, using the locale defined by looking up oclLocale in the current environment.
 				Otherwise, returns the same string as
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">toReal() : Real[1] invalidating</code>

 </p>
 <p>Converts
 				<code class="code">self</code> to a Real value.
 			</p>
 <p>

 <code class="code">toString() : String[1]</code>

 </p>
 <p>Returns
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">toUpper() : String[1]</code>

 </p>
 <p>This is a deprecated variant of toUpperCase() preserving compatibility with traditional Eclipse OCL behaviour.</p>
 <p>

 <code class="code">toUpperCase() : String[1]</code>

 </p>
 <p>Converts
 				<code class="code">self</code> to upper case, using the locale defined by looking up oclLocale in the current environment.
 				Otherwise, returns the same string as
 				<code class="code">self</code>.
 			</p>
 <p>

 <code class="code">tokenize() : Sequence(String)</code>

 </p>
 <p>Partition
 				<code class="code">self</code> into a sequence substrings separated by any of space, line-feed, carriage-return, form-feed and horizontal-tab delimiters.
 				The delimiters are omitted from the return.
 			</p>
 <p>

 <code class="code">tokenize(delimiters : String[?]) : Sequence(String)</code>

 </p>
 <p>Partition
 				<code class="code">self</code> into a sequence substrings separated by characters in the delimiters. The delimiters are omitted from the return.
 			</p>
 <p>

 <code class="code">tokenize(delimiters : String[?], returnDelimiters : Boolean[?]) : Sequence(String)</code>

 </p>
 <p>Partition
 				<code class="code">self</code> into a sequence substrings separated by characters in the delimiters. If returnDelimeters is
 				true the returned sequence includes the delimiters, otherwise the delimiters are omitted.
 			</p>
 <p>

 <code class="code">trim() : String[1]</code>

 </p>
 <p>Return
 				<code class="code">self</code> with leading and trailing whitespace removed.
 			</p>
 </div>
 <div class="section" title="Type">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Type"></a>
 				<span class="bold"><strong>
 					<code class="code">Type</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The UML Type is the supertype of anything that may be used as a type.</p>
 <p>conformsTo
 				<a class="link" href="#OclType" title="OclType">
 					<code class="code">OclType</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">conformsTo(type2 : Type[?]) : Boolean[1]</code>

 </p>
 <p>Returns true if type2 conforms to self.</p>
 </div>
 <div class="section" title="UniqueCollection(T)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="UniqueCollection"></a>
 				<span class="bold"><strong>
 					<code class="code">UniqueCollection(T)</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The UniqueCollection type provides the shared functionality of the OrderedSet and Set
 				collections for which the elements are unique.
 				The common supertype of UniqueCollection is Collection.</p>
 <p>conformsTo
 				<a class="link" href="#Collection" title="Collection(T)">
 					<code class="code">Collection(T)</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">-(s : UniqueCollection(OclAny)) : UniqueCollection(T)</code>
 				precedence:
 				<code class="code">ADDITIVE</code>

 </p>
 <p>The elements of
 				<code class="code">self</code>, which are not in s.
 			</p>
 <p>

 <code class="code">intersection(c : Collection(T)) : Set(T)</code>

 </p>
 <p>The intersection of
 				<code class="code">self</code> and c (i.e., the set of all elements that are in both
 				<code class="code">self</code> and c).
 			</p>
 <p>

 <code class="code">symmetricDifference(s : UniqueCollection(OclAny)) : Set(T)</code>

 </p>
 <p>The set containing all the elements that are in
 				<code class="code">self</code> or s, but not in both.
 			</p>
 <p>

 <code class="code">union(s : UniqueCollection(T)) : Set(T)</code>

 </p>
 <p>The set consisting of all elements in
 				<code class="code">self</code> and all elements in s.
 			</p>
 <p>

 <span class="bold"><strong>Iterations</strong></span>

 </p>
 <p>

 <code class="code">sortedBy(i : T[?] | lambda : Lambda T() : OclAny[?]) : OrderedSet(T)</code>

 </p>
 <p>Results in the ordered set containing all elements of the source collection.
 				The element for which body has the lowest value comes first, and so on.
 				The type of the body expression must have the &lt; operation defined.
 				The &lt; operation must return a Boolean value and must be transitive (i.e., if a &lt; b and b &lt; c, then a &lt; c).</p>
 </div>
 <div class="section" title="UnlimitedNatural">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="UnlimitedNatural"></a>
 				<span class="bold"><strong>
 					<code class="code">UnlimitedNatural</code>
 				</strong></span>

 </h2>
 </div>
 </div>
 </div>
 <p>The standard type UnlimitedNatural is used to encode the non-negative values of a multiplicity specification.
 				This includes a special
 				<span class="emphasis"><em>unlimited</em></span> value (*) that encodes the upper value of  a multiplicity specification.
 				UnlimitedNatural is itself an instance of the metatype UnlimitedNaturalType.
 			</p>
 <p>Note that UnlimitedNatural is not a subclass of Integer.</p>
 <p>conformsTo
 				<a class="link" href="#OclComparable" title="OclComparable">
 					<code class="code">OclComparable</code>
 				</a>

 </p>
 <p>

 <span class="bold"><strong>Operations</strong></span>

 </p>
 <p>

 <code class="code">max(i : OclSelf[?]) : UnlimitedNatural[1]</code>

 </p>
 <p>The maximum of
 				<code class="code">self</code> an i.
 			</p>
 <p>

 <code class="code">min(i : OclSelf[?]) : UnlimitedNatural[1]</code>

 </p>
 <p>The minimum of
 				<code class="code">self</code> an i.
 			</p>
 <p>

 <code class="code">oclAsType(TT)(type : TT[?]) : TT[?] invalidating</code>

 </p>
 <p>Evaluates to
 				<code class="code">self</code>, where
 				<code class="code">self</code> is of the type identified by T.
 				The type T may be any classifier defined in the UML model;
 				if the actual type of
 				<code class="code">self</code> at evaluation time does not conform to T,
 				then the oclAsType operation evaluates to
 				<code class="code">invalid</code>.
 			</p>
 <p>The standard behavior is redefined for UnlimitedNatural. Numeric values may be converted to
 				Real or Integer, but the
 				<span class="emphasis"><em>unlimited</em></span> value may not.
 				Conversion of
 				<span class="emphasis"><em>unlimited</em></span> to Real or Integer returns
 				<code class="code">invalid</code>.
 			</p>
 <p>

 <code class="code">toInteger() : Integer[1] invalidating</code>

 </p>
 <p>Converts
 				<code class="code">self</code> to an Integer value unless
 				<code class="code">self</code> is
 				<span class="emphasis"><em>unlimited</em></span> in which case
 				<code class="code">self</code> is converted to
 				<code class="code">invalid</code>.
 			</p>
 </div>
 </div>
 <div class="chapter" title="Chapter&nbsp;4.&nbsp;Tutorials">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title">
 <a name="Tutorials"></a>Chapter&nbsp;4.&nbsp;Tutorials</h2>
 </div>
 </div>
 </div>
 <p>The
 			<a class="link" href="#OCLinEcoreTutorial" title="OCLinEcore tutorial">OCLinEcore tutorial</a> shows how
 		</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>to install OCL and the additional Editors and Examples</p>
 </li>
 <li class="listitem">
 <p>to use the OCLinEcore editor</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>to edit Ecore meta-models</p>
 </li>
 <li class="listitem">
 <p>to enrich Ecore meta-models with OCL invariants, bodies and values</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>to use embedded OCL for validation of models</p>
 </li>
 <li class="listitem">
 <p>to use the OCL Console to practice evaluation of OCL</p>
 </li>
 <li class="listitem">
 <p>to generate Java code for Ecore that uses the embedded OCL</p>
 </li>
 </ul>
 </div>
 <p>The
 			<a class="link" href="#OCLInterpreterTutorial" title="Working with Classic OCL">Working with Classic OCL tutorial</a> shows how
 		</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>the OCL Parser may be invoked from Java</p>
 </li>
 <li class="listitem">
 <p>the OCL evaluator may be invoked from Java</p>
 </li>
 </ul>
 </div>
 <div class="section" title="OCLinEcore tutorial">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OCLinEcoreTutorial"></a>OCLinEcore tutorial</h2>
 </div>
 </div>
 </div>
 <p>This tutorial has been updated for Eclipse Mars; Eclipse 4.5, EMF 2.11, OCL 6.0.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Some screenshots may be slightly out of date.</p>
 </li>
 </ul>
 </div>
 <div class="section" title="Overview">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Overview"></a>Overview </h3>
 </div>
 </div>
 </div>
 <p>In this example you will</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Create an Ecore model using the OCLinEcore text editor</p>
 </li>
 <li class="listitem">
 <p>Create a dynamic instance of that Ecore model</p>
 </li>
 <li class="listitem">
 <p>Enrich the Ecore model with OCL using the OCLinEcore text editor</p>
 </li>
 <li class="listitem">
 <p>Validate the model and observe the OCL enrichments</p>
 </li>
 <li class="listitem">
 <p>Use the Interactive OCL Console to execute the OCL enrichments</p>
 </li>
 </ul>
 </div>
 <p>The above is all performed without generating any Java code;
 					the models exploit EMF&rsquo;s dynamic capabilities and the OCL integration.</p>
 <p>You may then</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Create an Ecore genmodel</p>
 </li>
 <li class="listitem">
 <p>Generate Java code for the Ecore model that invokes the OCL expressions.</p>
 </li>
 </ul>
 </div>
 <p>See the
 					<a class="link" href="#DebuggerTutorial" title="Debugger tutorial">OCL Debugger tutorial</a> for debugging
 					See the
 					<a class="link" href="#CodeGenerationTutorial" title="Code Generation tutorial">Code Generator tutorial</a> for Java code generation
 				</p>
 </div>
 <div class="section" title="References">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="References"></a>References</h3>
 </div>
 </div>
 </div>
 <p>This tutorial assumes that the reader is familiar with generating models using EMF.
 					The reader is referred to
 					<a class="ulink" href="/help/topic/org.eclipse.emf.doc/tutorials/clibmod/clibmod.html" target="_new">Generating an EMF Model</a>.
 				</p>
 <p>Other references:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>The Object Constraint Language: Getting Your Models Ready for MDA. Jos Warmer and Anneke Kleppe. (Addison-Wesley Object Technology) </p>
 </li>
 <li class="listitem">
 <p>

 <a class="ulink" href="http://www.omg.org/spec/OCL" target="_new">OCL specification</a>.
 						</p>
 </li>
 <li class="listitem">
 <p>

 <a class="ulink" href="http://wiki.eclipse.org/OCL/OCLinEcore" target="_new">OCLinEcore wiki page</a>.
 						</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Installing the Eclipse OCL Examples">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLinEcoreTutorial-Installation"></a>Installing the Eclipse OCL Examples</h3>
 </div>
 </div>
 </div>
 <p>Please see the
 					<a class="link" href="#Installation" title="Installing the Eclipse OCL Examples and Editors">Instructions for installing the OCL Editors</a>.
 				</p>
 </div>
 <div class="section" title="Troubleshooting">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Troubleshooting"></a>Troubleshooting</h3>
 </div>
 </div>
 </div>
 <p>The editor currently provides syntax and semantic validation. It does not yet apply all the
 					well-formedness validation rules, so some problems may be unreported. This is work in progress.
 					Sometimes spurious errors are displayed, which may go away with a
 					<span class="bold"><strong>Save</strong></span>,
 					but may require an editor close and reopen.
 				</p>
 </div>
 <div class="section" title="Using the OCLinEcore text editor for Ecore">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="UsingtheOCLinEcoretexteditorforEcore"></a>Using the OCLinEcore text editor for Ecore</h3>
 </div>
 </div>
 </div>
 <p>There are many different (compatible) ways to create and edit Ecore models.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>An Ecore Model may be created from an XSD schema file</p>
 </li>
 <li class="listitem">
 <p>An Ecore Model may be created from a Rose model file</p>
 </li>
 <li class="listitem">
 <p>An Ecore Model may be created from annotated Java file</p>
 </li>
 <li class="listitem">
 <p>The Sample Ecore Editor provides tree editing</p>
 </li>
 <li class="listitem">
 <p>The Ecore Tools project provides graphical editing</p>
 </li>
 <li class="listitem">
 <p>Papyrus provides UML editing that may be converted to Ecore</p>
 </li>
 </ul>
 </div>
 <p>Here we introduce the OCLinEcore editor that provides text editing, which is
 					appropriate when a non-trivial amount of OCL enrichment is required.</p>
 <p>All the above approaches update a *.ecore file, so the user is free to choose
 					whichever editing approach is best suited for the planned changes.</p>
 <div class="section" title="Create a New EMF Project">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CreateaNewEMFProject"></a>Create a New EMF Project</h4>
 </div>
 </div>
 </div>
 <p>We will first create a new project for this example; so invoke
 						<span class="bold"><strong>File-&gt;New-&gt;Project...</strong></span>
 						(left-click the
 						<span class="bold"><strong>File</strong></span> menu, then left-click
 						<span class="bold"><strong>New</strong></span>, then left-click
 						<span class="bold"><strong>Project...</strong></span>).
 					</p>
 <p>In the
 						<span class="bold"><strong>New Project</strong></span> dialog left-click to expand
 						<span class="bold"><strong>Eclipse Modeling Framework</strong></span>, then left-click to select

 						<span class="bold"><strong>Empty EMF Project</strong></span>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-new_project.png"></div>
 <p>

 </p>
 <p>Left-click on
 						<span class="bold"><strong>Next</strong></span> and in the
 						<span class="bold"><strong>New Empty EMF Project</strong></span> dialog type
 						<span class="bold"><strong>Tutorial</strong></span> as the project name.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-new_empty_emf_project.png"></div>
 <p>

 </p>
 <p>Left-click on
 						<span class="bold"><strong>Finish</strong></span>.
 					</p>
 </div>
 <div class="section" title="Create a New Ecore Model">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CreateaNewEcoreModel"></a>Create a New Ecore Model</h4>
 </div>
 </div>
 </div>
 <p>We will now create a new model for this example.</p>
 <p>First right-click on the
 						<span class="bold"><strong>model</strong></span> folder in the
 						<span class="bold"><strong>Tutorial</strong></span> project to define the target folder and pop-up the context-sensitive menu.
 						Select
 						<span class="bold"><strong>New-&gt;Other...</strong></span> then select the
 						<span class="bold"><strong>OCLinEcore Ecore File</strong></span> from the
 						<span class="bold"><strong>OCL</strong></span> category.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-new_oclinecore-ecore.png"></div>
 <p>

 </p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 							The alternative
 							<span class="bold"><strong>OCLinEcore Text File</strong></span> creates a *.oclinecore text file which preserves whitespace and comments more faithfully but which must be converted to a *.ecore file for many modeling purposes.
 						</p>
 </blockquote>
 </div>
 <p></p>
 <p>Left-click
 						<span class="bold"><strong>Next</strong></span> and enter
 						<span class="bold"><strong>Tutorial.ecore</strong></span> as the file name.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-new_ecore_model_dialog.png"></div>
 <p>

 </p>
 <p>Left-click
 						<span class="bold"><strong>Finish</strong></span> to open up an editor with some minimal example content demonstrating
 					</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>the nesting of attributes or operations or invariants within classes within packages</p>
 </li>
 <li class="listitem">
 <p>use of OCL to define the body of an operation</p>
 </li>
 <li class="listitem">
 <p>the syntax for mutually opposite properties</p>
 </li>
 <li class="listitem">
 <p>use of OCL to define an invariant and a custom error message</p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-empty_oclinecore.png"></div>
 <p>

 </p>
 <p>Close the editor by left-clicking the cross on the editor tab.</p>
 <p>You can see the normal Ecore view of the file by right-clicking on the
 						<span class="bold"><strong>Tutorial.ecore</strong></span> file to pop-up the context-sensitive menu
 						and select
 						<span class="bold"><strong>Open With-&gt;Sample Ecore Model Editor</strong></span>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-empty_ecore.png"></div>
 <p>

 </p>
 <p>Close the editor by left-clicking the cross on the editor tab.</p>
 </div>
 <div class="section" title="Edit Ecore Model as OCLinEcore">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="OCLinEcoreMetamodel"></a>Edit Ecore Model as OCLinEcore</h4>
 </div>
 </div>
 </div>
 <p>We will now open the Ecore model using the OCLinEcore text editor and provide some
 						initial content.</p>
 <p>Right-click on the
 						<span class="bold"><strong>Tutorial.ecore</strong></span> file to pop-up the context-sensitive menu
 						and select
 						<span class="bold"><strong>Open With-&gt;OCLinEcore Editor</strong></span>.
 					</p>
 <p>Now follow the following procedure to cut and paste the following text into the editor.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>select all existing content (e.g. Ctrl-A)</p>
 </li>
 <li class="listitem">
 <p>delete all (e.g. Ctrl-X)</p>
 </li>
 <li class="listitem">
 <p>open
 								<a class="ulink" href="../references/4100-metamodel.oclinecore" target="_new">[Text for cut and paste]</a>

 </p>
 </li>
 <li class="listitem">
 <p>select and copy the text (e.g Ctrl-A and Ctrl-C) from the browser</p>
 </li>
 <li class="listitem">
 <p>paste (e.g Ctrl-V) in the original editor</p>
 </li>
 <li class="listitem">
 <p>save the contents (e.g. Ctrl-S)</p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-metamodel.png"></div>
 <p>

 </p>
 <p>The syntax is defined in
 						<a class="link" href="#OCLinEcore" title="The OCLinEcore Language">OCLinEcore</a>. It emulates OMG specifications with
 						&lsquo;name : type[multiplicity] { properties }&rsquo;.
 					</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">import</code> associates an alias with  an external EPackage.
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">package</code> introduces an EPackage with name, nsPrefix and nsURI.
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">class</code> introduces an EClass with name and optional superclasses.
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">attribute</code> introduces a property with a datatype type (an EAttribute).
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">property</code> introduces a property with a class type (an EReference).
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">#</code> introduces an opposite role name.
 							</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">_'xxx'</code> escapes an awkward or reserved word identifier.
 							</p>
 </li>
 </ul>
 </div>
 <p>The import URI is the URI of a Package, so in the example the
 						<code class="code">http://www.eclipse.org/emf/2002/Ecore</code>
 						is the URI of the model,
 						<code class="code">#</code> is the fragment separator and
 						<code class="code">/</code> is the path to
 						the Package at the root of the XMI document.
 					</p>
 <p>Completion assist (Ctrl Space) may be used for syntax assistance.</p>
 <p>Format (Ctrl-Shift F) may be used to auto-format a selected range.</p>
 <p>In order to discover a syntax for which completion assist is insufficient,
 						you may use the Sample Ecore Editor on a test file to create the kind of Ecore element
 						that you require, and then open the test file with the OCLinEcore editor to see the
 						corresponding textual syntax.</p>
 </div>
 <div class="section" title="The Tutorial Meta-Model">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="TheTutorialMetaModel"></a>The Tutorial Meta-Model</h4>
 </div>
 </div>
 </div>
 <p>The example meta-model models a library with members and books
 						and loans of books to members. It may be viewed graphically using the Ecore Tools
 						(not part of this tutorial).</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-ecore_diagram.png"></div>
 <p>

 </p>
 <p>Note that this diagram is an Ecore Diagram rather than a UML Diagram and so the default multiplicities for attributes is Ecore&rsquo;s [0..1] rather than OCLinEcore&rsquo;s and UML&rsquo;s [1..1].</p>
 <p>Note also that the OCL types
 						<code class="code">String</code> and
 						<code class="code">Integer</code> map
 						to
 						<code class="code">EString</code> and
 						<code class="code">EBigInteger</code> in Ecore.
 					</p>
 </div>
 </div>
 <div class="section" title="Create a Dynamic Model Instance">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CreateaDynamicModelInstance"></a>Create a Dynamic Model Instance</h3>
 </div>
 </div>
 </div>
 <p>At this point a corresponding EMF tutorial would show how to generate Java code for
 					the meta-model and an editor for the meta-model. Here we are concerned with modeling, so we will
 					continue with the models alone.</p>
 <p>In the editor view, double-click on
 					<span class="bold"><strong>Library</strong></span> to select it and then right-click to show the context-sensitive menu
 					and then left-click on
 					<span class="bold"><strong>Create Dynamic Instance...</strong></span> to start to create a
 					new Dynamic Model with
 					<code class="code">Library</code> at its root.
 				</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						Creating a Dynamic Instance requires a valid *.ecore file to exist. It does not work
 						when editing *.oclinecore files.</p>
 </blockquote>
 </div>
 <p></p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-create_dynamic_instance.png"></div>
 <p>

 </p>
 <p>In the
 					<span class="bold"><strong>Create Dynamic Instance</strong></span> dialog select
 					<span class="bold"><strong>Tutorial/model</strong></span> as
 					the parent folder and enter
 					<span class="bold"><strong>Tutorial.xmi</strong></span> as the file name for the
 					dynamic model instance and left-click
 					<span class="bold"><strong>Finish</strong></span>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-create_dynamic_instance_dialog.png"></div>
 <p>

 </p>
 <p>The model is automatically opened for editing.
 					If it is does not open with the Sample Reflective Ecore Model Editor,
 					close the editor and open explicitly using *Open With-&gt;Sample Reflective Ecore Model Editor).
 					This gives a tree-like presentation of the model. The properties of each node can
 					be seen in the Properties View.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-initial_model.png"></div>
 <p>

 </p>
 <p>(If the Properties View is not visible, right-click within the editor and left-click on

 					<span class="bold"><strong>Show Properties View</strong></span>.)
 				</p>
 <p>Select the Library and use give it a name such as
 					<code class="code">lib</code>.
 				</p>
 <p>From the right-button menu for
 					<code class="code">Library</code> use
 					<span class="bold"><strong>New Child-&gt;Books Book</strong></span> twice,
 					use
 					<span class="bold"><strong>New Child-&gt;Loans Loan</strong></span> once and
 					<span class="bold"><strong>New Child-&gt;Members Member</strong></span> three times
 					to populate the model with two books, one loan and three members.
 				</p>
 <p>Left-click to select each of the Books and Members in turn and enter a name
 					such as
 					<code class="code">b1</code> or
 					<code class="code">m2</code> using the Properties View. Specify that b1
 					has one copy and that b2 has 2 copies.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-model_copies.png"></div>
 <p>

 </p>
 <p>The books and members now have distinct titles in the outline.
 					When you left-click to select the Loan and edit its Book and Member attributes,
 					the associated pull-down has meaningful entries. Specify that the Loan is for

 					<code class="code">b2</code> by
 					<code class="code">m3</code>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-model_pull_down.png"></div>
 <p>

 </p>
 <p>The configuration so far is simple, three members, two books and one loan. We can
 					validate that this by right-clicking on the
 					<code class="code">Library</code> node, and left-clicking
 					to
 					<span class="bold"><strong>Validate</strong></span>
 					<code class="code">Library</code> and all its children.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-validate_menu.png"></div>
 <p>

 </p>
 <p>Since the model is so simple, it is difficult to have anything wrong; most of
 					the illegal modeling options such as a Loan composing rather than referencing a
 					Book are prevented by the Editor&rsquo;s enforcement of the meta-model.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-validation_successful.png"></div>
 <p>

 </p>
 <p>(If you have an error at this point, a
 					<span class="bold"><strong>Details</strong></span> button will lead you to some
 					diagnostics that may clarify the problem. Pasting the following XMI
 					into
 					<span class="bold"><strong>Tutorial.xmi</strong></span> should also
 					resolve an entry problem.)
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">&lt;?xml&nbsp;version="1.0"&nbsp;encoding="ASCII"?&gt;<br>
 &lt;tut:Library&nbsp;xmi:version="2.0"&nbsp;xmlns:xmi="http://www.omg.org/XMI"<br>
 &nbsp;&nbsp;&nbsp;&nbsp;xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br>
 &nbsp;&nbsp;&nbsp;&nbsp;xmlns:tut="http://www.eclipse.org/mdt/ocl/oclinecore/tutorial"<br>
 &nbsp;&nbsp;&nbsp;&nbsp;xsi:schemaLocation="http://www.eclipse.org/mdt/ocl/oclinecore/tutorial&nbsp;Tutorial.ecore"<br>
 &nbsp;&nbsp;&nbsp;&nbsp;name="lib"&gt;<br>
 &nbsp;&nbsp;&lt;books&nbsp;name="b1"&nbsp;copies="1"/&gt;<br>
 &nbsp;&nbsp;&lt;books&nbsp;name="b2"&nbsp;copies="2"/&gt;<br>
 &nbsp;&nbsp;&lt;loans&nbsp;book="//@books.1"&nbsp;member="//@members.2"/&gt;<br>
 &nbsp;&nbsp;&lt;members&nbsp;name="m1"/&gt;<br>
 &nbsp;&nbsp;&lt;members&nbsp;name="m2"/&gt;<br>
 &nbsp;&nbsp;&lt;members&nbsp;name="m3"/&gt;<br>
 &lt;/tut:Library&gt;<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>We will now create two further identical loans of
 					<code class="code">b2</code> by
 					<code class="code">m3</code>. This
 					may conveniently be performed by left-clicking to select the existing loan,
 					typing Ctrl-C to copy it, left-clicking to select the
 					<code class="code">Library</code> as the new parent,
 					then typing Ctrl-V to paste it on the library. Repeat so that there are three
 					identical loans.
 				</p>
 <p>Validating the library should still be successful, although it is clearly wrong for
 					the two copies of
 					<code class="code">b2</code> to participate in three loans.
 				</p>
 </div>
 <div class="section" title="Enrich the meta-model with OCL">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="EnrichthemetamodelwithOCL"></a>Enrich the meta-model with OCL</h3>
 </div>
 </div>
 </div>
 <p>The semantic constraint that a book cannot be borrowed more times than there are books
 					is a simple example of a constraint that cannot be expressed by simple multiplicities;
 					a more powerful capability is required that may potentially require evaluation
 					of functions of almost arbitrary complexity. The Object Constraint Language
 					provides this capability.</p>
 <p>The constraint can be realized as an invariant on a book that specifies that
 					that (the size of the (selection of loans involving the book)) is less than or equal
 					to (the number of copies of the book).</p>
 <div class="literallayout">
 <p>
 <code class="code">&nbsp;&nbsp;&nbsp;&nbsp;invariant&nbsp;SufficientCopies:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;library.loans-&gt;select(book=self)-&gt;size()&nbsp;&lt;=&nbsp;copies;<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>In more detail:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>an invariant is defined whose name is
 							<code class="code">SufficientCopies</code>

 </p>
 </li>
 <li class="listitem">
 <p>within the invariant on a Book,
 							<code class="code">self</code> is the instance of
 							<code class="code">Book</code> being validated.
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">library.loans</code>, which is short for
 							<code class="code">self.library.loans</code>, navigates to the library and then to all loans in the library.
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">-&gt;select(...)</code> is a collection iteration over the loans. It selects each loan for which its argument expression is true
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">book=self</code>, which is short for
 							<code class="code">aLoan : Loan | aLoan.book = self</code>, uses the
 							<code class="code">aLoan</code> iterator over each loan to select those for which the book is the book being validated
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">-&gt;size()</code> is a collection operation that just counts the number of selected loans
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">&lt;= copies</code>, which is short for
 							<code class="code">&lt;= self.copies</code> converts the count to
 							<code class="code">true</code> if it is consistent, or
 							<code class="code">false</code> if inconsistent.
 						</p>
 </li>
 </ul>
 </div>
 <p>Close the
 					<span class="bold"><strong>Tutorial.xmi</strong></span> editor before modifying its meta-model. (Beware that
 					a wide variety of unpleasant errors can occur if the meta-model is changed after
 					the model is loaded.)
 				</p>
 <p>Add the invariant shown below to the meta-model.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-metamodel2.png"></div>
 <p>


 <a class="ulink" href="../references/4100-metamodel2.oclinecore" target="_new">[Text for cut and paste]</a>

 </p>
 <p>The required semantic is expressed by the
 					<code class="code">SufficientCopies</code> invariant constraint for a Book.
 					For a valid model the SufficientCopies invariant must always be true.
 				</p>
 <p>If you reopen the
 					<span class="bold"><strong>Tutorial.xmi</strong></span> editor and invoke
 					<span class="bold"><strong>Validate</strong></span> for the
 					<code class="code">Library</code>,
 					you will now get a validation error. Left click
 					<span class="bold"><strong>Details</strong></span> for details.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-validation_unsuccessful.png"></div>
 <p>

 </p>
 <p>The
 					<span class="bold"><strong>Details</strong></span> identifies that the
 					<code class="code">SufficientCopies</code> invariant is not
 					satisfied for the
 					<code class="code">b2</code> book.
 				</p>
 <p>Alternatively you may invoke
 					<span class="bold"><strong>Live Validation</strong></span> so that validation happens automatically with
 					error icons and hover text identifying problems.
 				</p>
 <p>If you now change the first loan so that
 					<code class="code">b1</code> is borrowed and then validate
 					again, the problem is resolved. It is all right for
 					<code class="code">m3</code> to borrow
 					the one copy of
 					<code class="code">b1</code> and the two copies of
 					<code class="code">b2</code>.
 				</p>
 <p>Before introducing a further constraint of no duplicate loans, we will show
 					how OCL expressions can be exercised. OCL is a very powerful compact language;
 					the example hides a loop over all the loans. More complex examples may easily
 					involve three or four levels of hidden loops on a single line, but may equally
 					easily have simple errors. It is therefore helpful to simplify expressions
 					and use helper operations and properties to modularise them. These may then be
 					exercised using the OCL Console or debugged using the
 					<a class="link" href="#Debugger" title="Debugger (new in Luna)">OCL Debugger</a>.
 				</p>
 </div>
 <div class="section" title="The OCL Console">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLinEcoreTutorial-Console"></a>The OCL Console</h3>
 </div>
 </div>
 </div>
 <p>The OCL Console supports interactive execution of an OCL expression in the
 					context of a model instance.</p>
 <p>To make the OCL Console visible, first make the
 					<span class="bold"><strong>Console</strong></span> view visible by

 					<span class="bold"><strong>Window-&gt;Show View-&gt;Console</strong></span>. Then right click on the
 					<span class="bold"><strong>Open Console</strong></span> and
 					left click on
 					<span class="bold"><strong>Interactive Xtext OCL</strong></span>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-ocl_console_menu.png"></div>
 <p>

 </p>
 <p>Alternatively, you can just invoke
 					<span class="bold"><strong>OCL-&gt;Show Xtext OCL Console</strong></span> from the right button menu
 					within the
 					<span class="bold"><strong>Sample Ecore Editor</strong></span> or
 					<span class="bold"><strong>Sample Reflective Ecore Editor</strong></span>.
 				</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						The
 						<span class="bold"><strong>Xtext OCL</strong></span> console is new Xtext-based functionality that uses the Pivot binding. It is
 						faster, and more compliant with the OCL specification, than the
 						<span class="bold"><strong>OCL</strong></span> console that uses the
 						LPG parser and Ecore binding.
 					</p>
 </blockquote>
 </div>
 <p></p>
 <p>The
 					<span class="bold"><strong>Interactive Xtext OCL</strong></span> console comprises two main text panes. The upper pane
 					displays results. The lower pane supports entry of queries.
 				</p>
 <p>Left-click to select the
 					<code class="code">Library</code> in the
 					<span class="bold"><strong>Tutorial.xmi</strong></span> as the context
 					for a query, and then type
 					<code class="code">books</code> followed by a new line into the lower
 					pane of the console.
 				</p>
 <p>The result of evaluating this query for the Library is shown.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-books_query.png"></div>
 <p>

 </p>
 <p>Substantial OCL queries spanning many lines may be entered and so the cursor up
 					and cursor down keys move across lines. If you want to access an earlier query,
 					you may use the
 					<span class="bold"><strong>Page Up</strong></span> or
 					<span class="bold"><strong>Page Down</strong></span> keys to save typing them again.
 				</p>
 <p>You can examine the execution of the query within out example invariant by selecting each of the books
 					in turn and executing
 					<code class="code">library.loans-&gt;select(book=self)</code>, to see that
 					<code class="code">b1</code>
 					has one Loan and
 					<code class="code">b2</code> two.
 				</p>
 </div>
 <div class="section" title="Helper Features and Operations">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLinEcoreTutorialHelpers"></a>Helper Features and Operations</h3>
 </div>
 </div>
 </div>
 <p>We will now introduce some helper attributes and operations to make
 					the OCL clearer and provide a richer meta-model API.
 					Close the
 					<span class="bold"><strong>Tutorial.xmi</strong></span> editor and modify the meta-model to include
 					the derived
 					<code class="code">loans</code> property and the helper operation
 					<code class="code">isAvailable()</code>.
 					Simplify the invariant to use the derived property.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-metamodel3.png"></div>
 <p>


 <a class="ulink" href="../references/4100-metamodel3.oclinecore" target="_new">[Text for cut and paste]</a>

 </p>
 <p>Note that the derived property must also be volatile to avoid problems when
 					a model is loaded but has no content.</p>
 <p>Reopen
 					<span class="bold"><strong>Tutorial.xmi</strong></span> and select
 					<span class="bold"><strong>Book b2</strong></span> so that the derived property is visible in the
 					<span class="bold"><strong>Properties</strong></span> view.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-derived_property.png"></div>
 <p>

 </p>
 <p>The helper operation can be evaluated in the
 					<span class="bold"><strong>Console</strong></span> view, after closing and reopening, by selecting book
 					<code class="code">b2</code> and typing
 					<code class="code">isAvailable()</code> for execution.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-helper_operation.png"></div>
 <p>

 </p>
 <p>We will now add further helpers and constraints to enforce an
 					at most two loans per member policy and to require loans to be unique.</p>
 <p>(Don&rsquo;t forget to close
 					<span class="bold"><strong>Tutorial.xmi</strong></span> while changing its meta-model.)
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-metamodel4.png"></div>
 <p>


 <a class="ulink" href="../references/4100-metamodel4.oclinecore" target="_new">[Text for cut and paste]</a>

 </p>
 <p>The additional
 					<code class="code">books</code> property may be evaluated in the OCL
 					Console to show which books each member has on loan. The property may also be seen in the
 					<span class="bold"><strong>Properties</strong></span> view.
 				</p>
 <p>Select the library again and invoke
 					<span class="bold"><strong>Validate</strong></span> from the right button menu.
 					There are now two validation failures.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-two_validation_errors.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Generating Java Code">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLinEcoreTutorial-genmodel"></a>Generating Java Code</h3>
 </div>
 </div>
 </div>
 <p>We have shown how OCL may be used to enrich Ecore meta-models, how model instances can be created
 					and validated and how expressions can be evaluated, all without generating any Java code.</p>
 <p>Exactly the same facilities are available if you do generate Java code and as a result you gain some speed benefits. By default, in the Eclipse OCL 6.4.0 (Photon) release the generated Java code for OCL is interpreted and so the speed gains occur only for the EMF models.
 					In the
 					<a class="link" href="#CodeGenerationTutorial" title="Code Generation tutorial">Code Generation Tutorial</a>, a preliminary release of
 					the OCL to Java code generator is described, giving an approximately five-fold speed improvement
 					and eliminating the need for run-time compilation.
 				</p>
 <p>Generating Java code is exactly the same as for any other EMF project. (Prior to EMF 2.8, there was one important difference; you must explicitly set
 					<span class="bold"><strong>Operation Reflection</strong></span> to true. The default for this changed to true in EMF 2.8.)
 				</p>
 <p>Select the
 					<span class="bold"><strong>Tutorial.ecore</strong></span> file and invoke
 					<span class="bold"><strong>New-&gt;Other...</strong></span> from the right button menu
 					and select
 					<span class="bold"><strong>Eclipse Modeling Framework</strong></span> and
 					<span class="bold"><strong>EMF Generator Model</strong></span>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-new_emf_generator.png"></div>
 <p>

 </p>
 <p>Select
 					<span class="bold"><strong>Next</strong></span>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-new_emf_generator_model.png"></div>
 <p>

 </p>
 <p>Select
 					<span class="bold"><strong>Next</strong></span>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-new_emf_generator_model_ecore.png"></div>
 <p>

 </p>
 <p>Select
 					<span class="bold"><strong>Next</strong></span>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-new_emf_generator_model_load.png"></div>
 <p>

 </p>
 <p>Select
 					<span class="bold"><strong>Load</strong></span> and
 					<span class="bold"><strong>Next</strong></span>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-new_emf_generator_model_packages.png"></div>
 <p>

 </p>
 <p>Select
 					<span class="bold"><strong>Finish</strong></span>.
 				</p>
 <p>The
 					<span class="bold"><strong>Tutorial.genmodel</strong></span> editor opens.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-gen_model.png"></div>
 <p>

 </p>
 <p>Most of the default settings are suitable. The one that may not be is highlighted. Select the
 					root
 					<span class="bold"><strong>Tutorial</strong></span> and scroll down the
 					<span class="bold"><strong>Properties</strong></span> view and set
 					<span class="bold"><strong>Operation Reflection</strong></span>
 					to true if it is not already true. (As from EMF 2.8 the default is true.)
 				</p>
 <p>You may now invoke
 					<span class="bold"><strong>Generate Model Code</strong></span> from the right button menu of either
 					<span class="bold"><strong>Tutorial</strong></span>
 					to generate Java models that invoke OCL.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4100-gen_model_menu.png"></div>
 <p>

 </p>
 <div class="section" title="Java Details">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="JavaDetails"></a>Java Details</h4>
 </div>
 </div>
 </div>
 <p>You can check that the OCL appears in your Java by looking at
 						<span class="bold"><strong>tutorial.util.TutorialValidator.java</strong></span>
 						where you&rsquo;ll find the OCL expression as a String awaiting compilation at run-time, and
 						the validate invocation that triggers that compilation and execution.
 					</p>
 <div class="literallayout">
 <p>
 <code class="code">protected&nbsp;static&nbsp;final&nbsp;String&nbsp;MEMBER__AT_MOST_TWO_LOANS__EEXPRESSION&nbsp;=&nbsp;"\n"&nbsp;+<br>
 &nbsp;&nbsp;"\t\t\tloans-&gt;size()&nbsp;&lt;=&nbsp;2";<br>

 <br>
 public&nbsp;boolean&nbsp;validateMember_AtMostTwoLoans(Member&nbsp;member,&nbsp;DiagnosticChain<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;diagnostics,&nbsp;Map&lt;Object,&nbsp;Object&gt;&nbsp;context)&nbsp;{<br>
 &nbsp;&nbsp;return<br>
 &nbsp;&nbsp;&nbsp;&nbsp;validate<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(TutorialPackage.Literals.MEMBER,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;member,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;diagnostics,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;context,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"http://www.eclipse.org/emf/2002/Ecore/OCL",<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"AtMostTwoLoans",<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MEMBER__AT_MOST_TWO_LOANS__EEXPRESSION,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Diagnostic.ERROR,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DIAGNOSTIC_SOURCE,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0);<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>Similarly in
 						<span class="bold"><strong>BookImpl</strong></span> you will find the declaration of a cached delegate and
 						the dynamic invocation that provokes the first time compilation.
 					</p>
 <div class="literallayout">
 <p>
 <code class="code">protected&nbsp;static&nbsp;final&nbsp;EOperation.Internal.InvocationDelegate<br>
 &nbsp;&nbsp;IS_AVAILABLE__EINVOCATION_DELEGATE&nbsp;=&nbsp;((EOperation.Internal)<br>
 &nbsp;&nbsp;&nbsp;&nbsp;TutorialPackage.Literals.BOOK___IS_AVAILABLE).getInvocationDelegate();<br>

 <br>
 public&nbsp;boolean&nbsp;isAvailable()&nbsp;{<br>
 &nbsp;&nbsp;try&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;(Boolean)<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IS_AVAILABLE__EINVOCATION_DELEGATE.dynamicInvoke(this,&nbsp;null);<br>
 &nbsp;&nbsp;}<br>
 &nbsp;&nbsp;catch&nbsp;(InvocationTargetException&nbsp;ite)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;throw&nbsp;new&nbsp;WrappedException(ite);<br>
 &nbsp;&nbsp;}<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The OCL expression for the invocation delegate may be found in
 						<span class="bold"><strong>TutorialPackageImpl.createPivotAnnotations()</strong></span>.
 					</p>
 <div class="literallayout">
 <p>
 <code class="code">addAnnotation<br>
 &nbsp;&nbsp;(getBook__IsAvailable(),&nbsp;<br>
 &nbsp;&nbsp;&nbsp;source,&nbsp;<br>
 &nbsp;&nbsp;&nbsp;new&nbsp;String[]&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;"body",&nbsp;"loans-&gt;size()&nbsp;&lt;&nbsp;copies"<br>
 &nbsp;&nbsp;&nbsp;});&nbsp;&nbsp;&nbsp;&nbsp;<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 <div class="section" title="API Invariants">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="APIInvariants"></a>API Invariants</h4>
 </div>
 </div>
 </div>
 <p>The invariants we have used so far do not contribute to the class API.</p>
 <p>If you want to have fine grain control of which validations are performed,
 						perhaps because in some incremental context not all are appropriate, you
 						may use the operation form of an invariant. </p>
 <div class="literallayout">
 <p>
 <code class="code">&nbsp;&nbsp;class&nbsp;Book<br>
 &nbsp;&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;operation&nbsp;sufficientCopies(diagnostics&nbsp;:&nbsp;ecore::EDiagnosticChain,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;context&nbsp;:&nbsp;ecore::EMap&lt;ecore::EJavaObject,ecore::EJavaObject&gt;)&nbsp;:&nbsp;Boolean<br>
 &nbsp;&nbsp;&nbsp;&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;body:&nbsp;library.loans-&gt;select(book=self)-&gt;size()&nbsp;&lt;=&nbsp;copies;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;attribute&nbsp;name&nbsp;:&nbsp;String;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;attribute&nbsp;copies&nbsp;:&nbsp;Integer;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;property&nbsp;library#books&nbsp;:&nbsp;Library;<br>
 &nbsp;&nbsp;}<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>Note that the operation must have a Boolean return (true for valid) and
 						diagnostics and context arguments. </p>
 </div>
 </div>
 <div class="section" title="Summary">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Summary"></a>Summary</h3>
 </div>
 </div>
 </div>
 <p>To illustrate how to work with the OCL and Ecore as models we have</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Created an Ecore meta-model using the OCLinEcore text editor</p>
 </li>
 <li class="listitem">
 <p>Created a dynamic model instance from that meta-model</p>
 </li>
 <li class="listitem">
 <p>Enriched the meta-model with embedded OCL</p>
 </li>
 <li class="listitem">
 <p>Used the embedded OCL while validating the model</p>
 </li>
 <li class="listitem">
 <p>Queried the model using the Interactive OCL Console.</p>
 </li>
 <li class="listitem">
 <p>Evaluated OCL embedded in the meta-model in the Console.</p>
 </li>
 </ul>
 </div>
 <p>To use OCL and Ecore as generated Java models we have</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Generated Java that exploits the embedded OCL.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="section" title="Complete OCL tutorial">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="CompleteOCLTutorial"></a>Complete OCL tutorial</h2>
 </div>
 </div>
 </div>
 <p>This tutorial has been updated for Eclipse Mars: Eclipse 4.5, EMF 2.11, OCL 6.0.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Some screenshots may be slightly out of date.</p>
 </li>
 </ul>
 </div>
 <div class="section" title="Overview">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Overview2"></a>Overview </h3>
 </div>
 </div>
 </div>
 <p>In this example you will</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Get an Overview of the Complete OCL language</p>
 </li>
 <li class="listitem">
 <p>Load a Complete OCL document into a third party application</p>
 </li>
 <li class="listitem">
 <p>Enhance Ecore validation for derived properties</p>
 </li>
 <li class="listitem">
 <p>Validate an Ecore model using additional Complete OCL validation</p>
 </li>
 <li class="listitem">
 <p>Enhance UML validation</p>
 </li>
 <li class="listitem">
 <p>Validate a UML model using additional Complete OCL validation</p>
 </li>
 <li class="listitem">
 <p>Enhance Xtext validation</p>
 </li>
 <li class="listitem">
 <p>Validate an Xtext grammar using additional Complete OCL validation</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Complete OCL Utility">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CompleteOCLUtility"></a>Complete OCL Utility</h3>
 </div>
 </div>
 </div>
 <p>By itself, OCL is almost useless, since without any models to operate on, the constraints cannot achieve a great deal.</p>
 <p>The simplest way to make OCL useful is to embed OCL expressions within a model to enrich the basic structural characteristics of a model with more complex behavior. OCLinEcore provides this capability for Ecore models. Papyrus provides comparable capabilities for UML models.</p>
 <p>This tutorial introduces the Complete OCL language which may be used to provide a self-standing document that complements a pre-existing meta-model.</p>
 </div>
 <div class="section" title="Load Complete OCL Tutorial Example Project">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="LoadCompleteOCLTutorialExampleProject"></a>Load Complete OCL Tutorial Example Project</h3>
 </div>
 </div>
 </div>
 <p>All the material for this tutorial is available as part of the CompleteOCLTutorial Example project that you
 					may load by selecting
 					<span class="bold"><strong>New</strong></span> then
 					<span class="bold"><strong>Example...</strong></span> using the right button context menu of the Project Explorer. This
 					should give the
 					<span class="bold"><strong>New Example</strong></span> dialog in which you can select the
 					<span class="bold"><strong>OCL (OCL Constraint Language) Plugins</strong></span> and the
 					<span class="bold"><strong>Complete OCL Tutorial</strong></span> and then
 					<span class="bold"><strong>Next</strong></span>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-new-complete-ocl-tutorial1.png"></div>
 <p>

 </p>
 <p>Then
 					<span class="bold"><strong>Finish</strong></span>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-new-complete-ocl-tutorial2.png"></div>
 <p>

 </p>
 <p>If you do not see these example projects, follow the
 					<a class="link" href="#Installation" title="Installing the Eclipse OCL Examples and Editors">Instructions for installing the OCL Editors</a>.
 				</p>
 <p>The resulting project has a few test files.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-complete-ocl-tutorial-project.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Complete OCL Language Overview">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CompleteOCLTutorial-language"></a>Complete OCL Language Overview</h3>
 </div>
 </div>
 </div>
 <p>The Complete OCL language is described in detail in the
 					<a class="link" href="#CompleteOCL" title="The Complete OCL Language">Complete OCL</a> section of this documentation.
 					In this tutorial we will provide just a brief overview of the language.
 					If not already open, double click on
 					<span class="bold"><strong>ExtraEcoreValidation.ocl</strong></span> to show the following text that provides examples of many
 					important aspects of the Complete OCL syntax.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-extra-ecore-content.png"></div>
 <p>

 </p>
 <div class="section" title="import declarations">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="importdeclarations"></a>import declarations</h4>
 </div>
 </div>
 </div>
 <p>The import statement is a serious omission from the OMG specification, since without it, any attempt to
 						align the Complete OCL constraints with external models relies on implementation-specific magic. The import
 						statement is therefore an Eclipse OCL extension that is likely to be part of a future OCL specification revision.</p>
 <p>Zero or more import statements may be present to specify the URIs of external model elements and optionally
 						alias names for those elements. In the example:</p>
 <div class="literallayout">
 <p>
 <code class="code">import&nbsp;ecore&nbsp;:&nbsp;'http://www.eclipse.org/emf/2002/Ecore#/'<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>

 <code class="code">http://www.eclipse.org/emf/2002/Ecore</code> specifies the URI of the Ecore metamodel and
 						<code class="code">#/</code> is the fragment URI
 						navigating to the root element which is the Ecore package. The
 						<code class="code">ecore</code> specifies an alias for this package, which happens
 						to be the same as the name of the package. Within the Complete OCL document, the imported model element may be referred to by its
 						alias.
 					</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 							When using the Ecore and UML bindings, the Java API support for using Complete OCL documents requires implementation-specific magic;
 							the imported models must be loaded into the package registry by the invoking code. Import statements are not used.</p>
 <p>Prior to the Juno release, import statements were not understood and so there was a usage conflict between Pivot and Ecore/UML bindings. Preparation of a
 							Complete OCL document using the Xtext editor, or usage with Pivot model and Xtext parser required import statements.
 							But re-use with the Ecore and UML LPG parser required the import statements to be removed.</p>
 <p>In Juno, the LPG parser ignores the import statements, so they may be left in.</p>
 </blockquote>
 </div>
 <p></p>
 </div>
 <div class="section" title="package context declaration">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="packagecontextdeclaration"></a>package context declaration</h4>
 </div>
 </div>
 </div>
 <p>A package context declaration may bracket declarations that complement model elements within the
 						complemented package.</p>
 <div class="literallayout">
 <p>
 <code class="code">package&nbsp;ecore<br>

 <br>
 ...<br>

 <br>
 endpackage<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>This specifies that additional Complete OCL declarations will complement the pre-existing declarations of
 						the
 						<code class="code">ecore</code> package.
 					</p>
 <p>Multiple package context declarations may be used to complement multiple packages.</p>
 <p>The package context declaration may be omitted if subsequent classifier context declarations have a fully qualified
 						name identifying the package.</p>
 </div>
 <div class="section" title="classifier context declaration">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="classifiercontextdeclaration"></a>classifier context declaration</h4>
 </div>
 </div>
 </div>
 <p>A classifier context declaration introduces declarations that complement subsequent model elements within the
 						complemented classifier.</p>
 <div class="literallayout">
 <p>
 <code class="code">context&nbsp;EModelElement<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The classifier context is terminated by a
 						<code class="code">context</code> or an
 						<code class="code">endpackage</code>.
 					</p>
 </div>
 <div class="section" title="feature definitions">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="featuredefinitions"></a>feature definitions</h4>
 </div>
 </div>
 </div>
 <p>Additional operations and properties may be defined for use within the Complete OCL document. These features
 						may be used as if they were part of the complemented meta-model.</p>
 <div class="literallayout">
 <p>
 <code class="code">def:&nbsp;asError(verdict&nbsp;:&nbsp;Boolean)&nbsp;:&nbsp;Boolean&nbsp;=<br>
 	if&nbsp;verdict&nbsp;then&nbsp;true&nbsp;else&nbsp;null&nbsp;endif<br>

 <br>
 def:&nbsp;hasDerivation&nbsp;:&nbsp;Boolean&nbsp;=&nbsp;eAnnotations-&gt;select(source.startsWith(<br>
 		'http://www.eclipse.org/emf/2002/Ecore/OCL'))-&gt;notEmpty()<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>A definition starts with the new feature name, then the parameters for operations and the feature type followed by an OCL expression that evaluates the operation or the property.</p>
 <p>For properties such as
 						<code class="code">hasDerivation</code> there is very little difference between a property definition
 						<code class="code">hasDerivation</code> and a parameter-less operation definition
 						<code class="code">hasDerivation()</code>. The property definition
 						and usage is two characters shorter and may seem more natural. The operation definition has the advantage that
 						it can be overloaded in derived classes.
 					</p>
 </div>
 <div class="section" title="class invariants">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="classinvariants"></a>class invariants</h4>
 </div>
 </div>
 </div>
 <p>Invariants may be imposed on a complemented meta-model. The invariant comprises the name of the invariant followed by an OCL expression that
 						evaluates true when the invariant is satisfied.</p>
 <div class="literallayout">
 <p>
 <code class="code">inv&nbsp;DerivationIsTransient:&nbsp;hasDerivation&nbsp;implies&nbsp;transient<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>These invariants are executed when a model is validated in an application that has loaded the complementing Complete OCL document. The significance of this is explained in
 						<a class="link" href="#LoadCompleteOCLResource" title="OCL->Load Document Menu Action">OCL-&gt;Load Document Menu Action</a>.
 					</p>
 <p>The readability of constraints can be significantly enhanced by the use of let-variables or the re-use, as above, of the
 						<code class="code">hasDerivation</code> helper property.
 					</p>
 </div>
 <div class="section" title="custom messages">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="custommessages"></a>custom messages</h4>
 </div>
 </div>
 </div>
 <p>Eclipse OCL supports two extensions to invariants that allow the validation failure messages and severities to be customized.</p>
 <div class="literallayout">
 <p>
 <code class="code">inv&nbsp;DerivationIsVolatile(<br>
 '"volatile"&nbsp;must&nbsp;be&nbsp;specified&nbsp;for&nbsp;derived&nbsp;feature&nbsp;'&nbsp;+&nbsp;self.toString()):<br>
 asError(hasDerivation&nbsp;implies&nbsp;volatile)<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The invariant name may be followed by a parenthesized OCL expression that computes a String to be used as the validation failure message.</p>
 <p>The severity of a validation failure may be controlled by the non-true value evaluated by the invariant expression.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>a
 								<code class="code">false</code> return indicates a warning severity
 							</p>
 </li>
 <li class="listitem">
 <p>a
 								<code class="code">null</code> return indicates an error severity
 							</p>
 </li>
 <li class="listitem">
 <p>an
 								<code class="code">invalid</code> return indicates a fatal severity
 							</p>
 </li>
 </ul>
 </div>
 <p>See
 						<a class="link" href="#Integration-Messages" title="Custom Validation Messages">Custom Validation Messages</a> for more details.
 					</p>
 </div>
 <div class="section" title="operation and property context declarations">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="operationandpropertycontextdeclarations"></a>operation and property context declarations</h4>
 </div>
 </div>
 </div>
 <p>Complete OCL also allows an incomplete operation or property declaration in the complemented meta-model to be completed.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>initial value expressions or derived value constraints may be specified for properties.</p>
 </li>
 <li class="listitem">
 <p>body expressions and precondition/postcondition constraints may be specified for operations.</p>
 </li>
 </ul>
 </div>
 <p>These facilities are of limited use since OCLinEcore avoids the need for incomplete meta-models.</p>
 </div>
 </div>
 <div class="section" title="OCL->Load Document Menu Action">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="LoadCompleteOCLResource"></a>OCL-&gt;Load Document Menu Action </h3>
 </div>
 </div>
 </div>
 <p>The major disclaimer in the above is that the Complete OCL only complements the complemented meta-model in applications
 					that have loaded the Complete OCL.</p>
 <p>Prior to the Juno release, this meant that Complete OCL was only usable in custom Java applications since no standard
 					modeling applications would load the complementing document.</p>
 <p>The
 					<span class="bold"><strong>OCL-&gt;Load Document</strong></span> menu action enables a Complete OCL document to be loaded into a wide variety of applications.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-load-complete-ocl-resource-menu.png"></div>
 <p>

 </p>
 <p>The
 					<span class="bold"><strong>OCL-&gt;Load Document</strong></span> menu action is added to the right button menu of applications with a ResourceSet accessible from the current selection.
 				</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						It has been observed that the extra menu action is not always immediately available, so if you do not see it, hit
 						<span class="bold"><strong>Esc</strong></span> to cancel the menu, select something corresponding to a model object and right click again.
 					</p>
 </blockquote>
 </div>
 <p></p>
 <p>In Mars, suitable applications are</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>an editor generated from an Ecore meta-model</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>the Sample Ecore Editor</p>
 </li>
 <li class="listitem">
 <p>the UML Model Editor</p>
 </li>
 <li class="listitem">
 <p>the Papyrus Model Editor</p>
 </li>
 <li class="listitem">
 <p>your model editor</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>an editor generated by Xtext</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>the Xtext Editor</p>
 </li>
 <li class="listitem">
 <p>the MWE2 Editor</p>
 </li>
 <li class="listitem">
 <p>the OCLinEcore Editor</p>
 </li>
 <li class="listitem">
 <p>your DSL editor</p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>The
 					<span class="bold"><strong>OCL-&gt;Load Document</strong></span> menu action activates the
 					<span class="bold"><strong>Load Complete OCL Document</strong></span> dialog in which you can browse Registered Complete OCL Documents, the File system or the Workspace for one or more Complete OCL documents to load, or often more conveniently you can just Drag and Drop them from an Operating System Explorer or an Eclipse Explorer.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-load-complete-ocl-resource-dialog.png"></div>
 <p>

 </p>
 <p>After clicking
 					<span class="bold"><strong>OK</strong></span> the documents load.
 				</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						Behind the scenes, it is necessary to install global wrappers around all complemented packages. These wrappers are sensitive to the ResourceSet for which complementing has been requested and so although this incurs a small performance penalty for use of the complemented packages in other applications, it should not affect the functional behavior of other applications. </p>
 </blockquote>
 </div>
 <p></p>
 </div>
 <div class="section" title="Example Complete OCL complements for Ecore">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CompleteOCLTutorial-EcoreComplements"></a>Example Complete OCL complements for Ecore</h3>
 </div>
 </div>
 </div>
 <p>The Sample Ecore Editor has acquired many useful validation rules, so that for many usages just invoking
 					<span class="bold"><strong>Validate</strong></span> is quite sufficient. But what if it isn&rsquo;t? Perhaps you have some style conventions that you wish to apply. Perhaps the built-in rules are not sufficient.
 				</p>
 <p>Prior to Juno and the
 					<span class="bold"><strong>OCL-&gt;Load Document</strong></span> capability, your only choice would be to check out the Ecore Editor and create a custom variant. Now you can use Complete OCL to extend the Sample Ecore Editor.
 				</p>
 <p>We will revisit the
 					<span class="bold"><strong>ExtraEcoreValidation.ocl</strong></span> document that we have just examined and use it to rectify inadequate checking of derived properties by the Sample Ecore Editor. The document provides six invariants, at least three of which detect problems that were encountered by users during the Indigo release cycle.
 				</p>
 <div class="section" title="DerivationIsVolatile">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="DerivationIsVolatile"></a>DerivationIsVolatile</h4>
 </div>
 </div>
 </div>
 <p>The EMF code generation templates have a simple treatment of
 						<code class="code">volatile</code>. Non-volatile variables have an associated field which is returned by the
 						<code class="code">get</code> operation. This overrides any derivation that might be supplied.
 					</p>
 <div class="literallayout">
 <p>
 <code class="code">inv&nbsp;DerivationIsVolatile:&nbsp;asError(hasDerivation&nbsp;implies&nbsp;volatile)<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>We therefore want to diagnose that if an EStructuralFeature has a derivation then the volatile declaration is also present to avoid the derivation being ignored.</p>
 <p>This problem is so serious that the basic expression is wrapped in the
 						<code class="code">asError</code> operation to convert the
 						default
 						<code class="code">true</code> /
 						<code class="code">false</code> okay/warning severity into the
 						<code class="code">true</code> /
 						<code class="code">null</code> okay/error severity.
 					</p>
 </div>
 <div class="section" title="DerivationIsTransient">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="DerivationIsTransient"></a>DerivationIsTransient</h4>
 </div>
 </div>
 </div>
 <p>The EMF code generation templates have a similarly simple treatment of
 						<code class="code">transient</code>. Non-transient variables will be
 						serialized as part of a model save. This is not usually appropriate since the derived value is redundant and can be
 						recomputed when the model is loaded again.
 					</p>
 <div class="literallayout">
 <p>
 <code class="code">inv&nbsp;DerivationIsTransient:&nbsp;hasDerivation&nbsp;implies&nbsp;transient<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>We therefore want to diagnose that a derivation is not serialized because of a default non-transient declaration.</p>
 </div>
 <div class="section" title="DerivationIsNotComposed">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="DerivationIsNotComposed"></a>DerivationIsNotComposed</h4>
 </div>
 </div>
 </div>
 <p>Composition is handled directly by EMF and it is not clear that it is appropriate to define an alternate
 						meaning of composition. It is pretty certain that EMF will not permit an alternate semantics.</p>
 <div class="literallayout">
 <p>
 <code class="code">inv&nbsp;DerivationIsNotComposed:&nbsp;asError(hasDerivation&nbsp;implies&nbsp;not&nbsp;containment)<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>We therefore want to diagnose if a derivation is attempting to specify alternate composition semantics and
 						report an error if this occurs.</p>
 </div>
 <div class="section" title="DerivationWithOppositeHasOppositeDerivation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="DerivationWithOppositeHasOppositeDerivation"></a>DerivationWithOppositeHasOppositeDerivation</h4>
 </div>
 </div>
 </div>
 <p>Opposites are also handled directly by EMF, but it is possible to replace this functionality. However if the
 						forward functionality is replaced, it is very unlikely that EMF&rsquo;s default reverse functionality will be appropriate.</p>
 <div class="literallayout">
 <p>
 <code class="code">inv&nbsp;DerivationWithOppositeHasOppositeDerivation:<br>
 	hasDerivation&nbsp;and&nbsp;eOpposite&nbsp;&lt;&gt;&nbsp;null&nbsp;implies&nbsp;eOpposite.hasDerivation<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>We therefore want to diagnose that a derivation that redefines the forward semantic of opposite also redefines
 						the corresponding reverse semantics.</p>
 </div>
 <div class="section" title="DerivationIsUninitialized">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="DerivationIsUninitialized"></a>DerivationIsUninitialized</h4>
 </div>
 </div>
 </div>
 <p>An initial value for a property may be specified as a simple default value or as a derived expression.</p>
 <div class="literallayout">
 <p>
 <code class="code">inv&nbsp;DerivationIsUninitialized:<br>
 	hasDerivation&nbsp;implies&nbsp;defaultValue.oclIsUndefined()<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>We want to diagnose the occlusion of the derived expression by a default value.</p>
 </div>
 <div class="section" title="DerivationDoesNotResolveProxies">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="DerivationDoesNotResolveProxies"></a>DerivationDoesNotResolveProxies</h4>
 </div>
 </div>
 </div>
 <p>Derived expressions are not references.</p>
 <div class="literallayout">
 <p>
 <code class="code">inv&nbsp;DerivationDoesNotResolveProxies:<br>
 	hasDerivation&nbsp;implies&nbsp;not&nbsp;resolveProxies<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>We can therefore diagnose whether the EMF proxy resolution logic is not suppressed. </p>
 </div>
 </div>
 <div class="section" title="Validating Ecore with additional Complete OCL">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CompleteOCLTutorial-EcoreValidation"></a>Validating Ecore with additional Complete OCL</h3>
 </div>
 </div>
 </div>
 <p>In the
 					<a class="link" href="#CompleteOCLTutorial-EcoreComplements" title="Example Complete OCL complements for Ecore">previous section</a> we described additional Complete OCL validation constraints to detect problems with inadequate Sample Ecore diagnosis of derived properties. We will now apply those constraints to a test file.
 				</p>
 <p>Select
 					<span class="bold"><strong>EcoreTestFile.ecore</strong></span> and use the right button menu to
 					<span class="bold"><strong>Open With-&gt;Sample Ecore Model Editor</strong></span>. This is probably the default for double-clicking with the left button, but if you open with the OCLinEcore editor the required validation will not work (in Juno).
 				</p>
 <p>Now right click within the Sample Ecore Editor pane as described in
 					<a class="link" href="#LoadCompleteOCLResource" title="OCL->Load Document Menu Action">OCL-&gt;Load Document Menu Action</a> and load
 					<span class="bold"><strong>ExtraEcoreValidation.ocl</strong></span>. An additional Resource is shown in the editor tree.
 				</p>
 <p>Select a model element such as the
 					<span class="bold"><strong>Bad</strong></span> package and use the right button menu to invoke
 					<span class="bold"><strong>Validate</strong></span>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-extra-ecore-validation.png"></div>
 <p>

 </p>
 <p>This shows an error. Depending on the order in which the constraints are evaluated, you may also see one or two warnings. You should use the
 					<a class="link" href="#ValidityView" title="Validity View (new in Luna)">Validity View</a> to see all failures.
 				</p>
 <p>If we now open
 					<span class="bold"><strong>EcoreTestFile.ecore</strong></span> with the OCLinEcore editor we can see that the
 					<span class="bold"><strong>transient</strong></span> and
 					<span class="bold"><strong>volatile</strong></span> keywords are indeed missing.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-extra-ecore-oclinecore.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Editing the Complete OCL">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CompleteOCLTutorial-Updating"></a>Editing the Complete OCL</h3>
 </div>
 </div>
 </div>
 <p>You may edit the Complete OCL to experiment with alternate constraints or messages.</p>
 <p>However the Complete OCL complements the meta-model and EMF does not support live modification of meta-models. It is therefore necessary to restart the Sample Ecore Editor
 					and Reload the modified Complete OCL document in order to exploit the changes.</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						A solution for this may occur in a future release.</p>
 </blockquote>
 </div>
 <p></p>
 </div>
 <div class="section" title="Example Complete OCL complements for UML">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CompleteOCLTutorial-UMLComplements"></a>Example Complete OCL complements for UML</h3>
 </div>
 </div>
 </div>
 <p>The extension of the Sample Ecore Editor validation described in
 					<a class="link" href="#CompleteOCLTutorial-EcoreValidation" title="Validating Ecore with additional Complete OCL">Validating Ecore with additional Complete OCL</a> is applicable to any tree editor generated by EMF tooling.
 				</p>
 <p>The
 					<span class="bold"><strong>ExtraUMLValidation.ocl</strong></span> file provides a very simple style check that class names start with an upper case letter.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-extra-uml-content.png"></div>
 <p>

 </p>
 <p>The UML meta-model is imported and an invariant is specified for the Class classifier which is fully qualified to avoid the need for a surrounding package context declaration.</p>
 <p>You may open the
 					<span class="bold"><strong>PapyrusTestFile.uml</strong></span> with the UML Model Editor, load the
 					<span class="bold"><strong>ExtraUMLValidation.ocl</strong></span>, select the
 					<span class="bold"><strong>Model</strong></span> and then
 					<span class="bold"><strong>Validate</strong></span> in the same way as for the Ecore example.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-extra-uml-validation.png"></div>
 <p>

 </p>
 <p>Unfortunately the Papyrus UML editor does not use the EValidator framework and so loading Complete OCL documents into Papyrus fails to enhance validation capabilities. To use additional Complete OCL functionality, you may load and validate in the UML Model Editor, then start the Papyrus editor which will then show the problem markers on diagram elements. Alternatively you may use
 					<a class="link" href="#ValidityView" title="Validity View (new in Luna)">Validity View</a> concurrently with Papyrus.
 				</p>
 </div>
 <div class="section" title="Example Complete OCL complements for Xtext">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CompleteOCLTutorial-XtextComplements"></a>Example Complete OCL complements for Xtext</h3>
 </div>
 </div>
 </div>
 <p>Xtext editors use EValidator and so a Complete OCL document may be loaded into an Xtext editor, including Xtext itself, to provide enhanced validation.</p>
 <p>The
 					<span class="bold"><strong>ExtraXtextValidation.ocl</strong></span> file provides some demonstration style checks.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-extra-xtext-content.png"></div>
 <p>

 </p>
 <p>The Xtext root package is imported and within the package declaration context for the
 					<span class="bold"><strong>xtext</strong></span> package, invariants are supplied for four classes. These are all just examples of how constraints may use the Xtext model. It is not suggested that users should use all of these constraints for real grammars.
 				</p>
 <div class="section" title="NoAnonymousImports">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="NoAnonymousImports"></a>NoAnonymousImports</h4>
 </div>
 </div>
 </div>
 <div class="literallayout">
 <p>
 <code class="code">context&nbsp;ReferencedMetamodel<br>
 inv&nbsp;NoAnonymousImports:&nbsp;alias&nbsp;&lt;&gt;&nbsp;null<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>This invariant diagnoses whether any import statements omit the
 						<code class="code">as xxxx</code> model name.
 					</p>
 </div>
 <div class="section" title="NoActions">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="NoActions"></a>NoActions</h4>
 </div>
 </div>
 </div>
 <div class="literallayout">
 <p>
 <code class="code">context&nbsp;Action<br>
 inv&nbsp;NoActions&nbsp;:&nbsp;false<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>This invariant diagnoses whenever an
 						<code class="code">{xxx}</code> action statement is used.
 					</p>
 </div>
 <div class="section" title="CamelCaseName">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="CamelCaseName"></a>CamelCaseName</h4>
 </div>
 </div>
 </div>
 <div class="literallayout">
 <p>
 <code class="code">context&nbsp;ParserRule<br>
 inv&nbsp;CamelCaseName&nbsp;:&nbsp;name.matches('[A-Z][A-Za-z]*')<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>This invariant verifies that the name of a parser rule starts with an upper case letter and uses only letters.  </p>
 </div>
 <div class="section" title="UpperName">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="UpperName"></a>UpperName</h4>
 </div>
 </div>
 </div>
 <div class="literallayout">
 <p>
 <code class="code">context&nbsp;xtext::TerminalRule<br>
 inv&nbsp;UpperName&nbsp;:&nbsp;name&nbsp;=&nbsp;name.toUpperCase()<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>This invariant verifies that the name of a terminal rule is uppercase.  </p>
 <p>You may open the
 						<span class="bold"><strong>XtextTestFile.xtext</strong></span> with the Xtext Editor, load the
 						<span class="bold"><strong>ExtraXtextValidation.ocl</strong></span> and then
 						<span class="bold"><strong>Validate</strong></span> in the same way as the Ecore example.
 					</p>
 <p>The additional validations appear as warning markers in the editor. </p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4300-extra-xtext-validation.png"></div>
 <p>

 </p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 							Unfortunately Xtext does not have a nice toString() method for its Concrete Syntax tree so the descriptions of erroneous elements are a little inelegant.</p>
 </blockquote>
 </div>
 <p></p>
 <p>You may edit the Xtext test file to delete the &ldquo;as ecore&rdquo; in the import statement and see that the additional Complete OCL constraints are contributing to the ongoing functionality of the editor. </p>
 </div>
 </div>
 <div class="section" title="Complete OCL Editor">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CompleteOCLEditor"></a>Complete OCL Editor</h3>
 </div>
 </div>
 </div>
 <p>The Complete OCL editor is invoked automatically for an existing or new *.ocl file.
 					You can create an empty file using either
 					<span class="bold"><strong>New-&gt;File</strong></span> or a partial content file using
 					<span class="bold"><strong>New-&gt;Other...</strong></span> followed by
 					<span class="bold"><strong>OCL</strong></span> and
 					<span class="bold"><strong>Complete OCL File</strong></span>. The editor is Xtext-based and so has most of the facilities that you find in many other Eclipse editors.
 				</p>
 </div>
 <div class="section" title="Royal and Loyal Example">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="RoyalandLoyalExample"></a>Royal and Loyal Example</h3>
 </div>
 </div>
 </div>
 <p>The Royal and Loyal Example was first provided by Jos Warmer and Anneke Kleppe in
 					<span class="emphasis"><em>The Object Constraint Language: Getting Your Models Ready for MDA</em></span> and has subsequently been used in many tutorials. The example provides substantial examples of Complete OCL and Essential OCL. The models are available by invoking
 					<span class="bold"><strong>New-&gt;Example...-&gt;OCL (Object Constraint Language) Plugins</strong></span>.
 				</p>
 </div>
 <div class="section" title="Summary">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Summary2"></a>Summary</h3>
 </div>
 </div>
 </div>
 <p>To illustrate how to work with Complete OCL we have</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Examined the Complete OCL language</p>
 </li>
 <li class="listitem">
 <p>Examined constraints to rectify inadequate Ecore validation of derived features</p>
 </li>
 <li class="listitem">
 <p>Loaded Complete OCL constraints to enhance validation of an Ecore model</p>
 </li>
 <li class="listitem">
 <p>Loaded Complete OCL constraints to enhance validation of a UML model</p>
 </li>
 <li class="listitem">
 <p>Loaded Complete OCL constraints to enhance validation of an Xtext grammar</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="section" title="Safe navigation tutorial">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="SafeNavigationTutorial"></a>Safe navigation tutorial</h2>
 </div>
 </div>
 </div>
 <p>This tutorial demonstrates the new safe navigation facilities of Eclipse Mars; Eclipse 4.5, EMF 2.11, OCL 6.0.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Some screenshots may be slightly out of date.</p>
 </li>
 </ul>
 </div>
 <div class="section" title="Overview">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Overview3"></a>Overview </h3>
 </div>
 </div>
 </div>
 <p>In this example you will</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>learn about navigation hazards</p>
 </li>
 <li class="listitem">
 <p>switch on safe navigation validation</p>
 </li>
 <li class="listitem">
 <p>use safe navigation to eliminate hazards</p>
 </li>
 <li class="listitem">
 <p>use null free declarations to avoid many safe navigation hazards</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="References">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="References2"></a>References</h3>
 </div>
 </div>
 </div>
 <p>This tutorial continues the
 					<a class="link" href="#OCLinEcoreTutorial" title="OCLinEcore tutorial">OCLinEcore tutorial</a>.
 				</p>
 </div>
 <div class="section" title="Evaluation hazards">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Evaluationhazards"></a>Evaluation hazards</h3>
 </div>
 </div>
 </div>
 <p>Evaluation of OCL expressions can give invalid results for internal problems</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>divide by zero</p>
 </li>
 <li class="listitem">
 <p>index out of bound for an Ordered Collection</p>
 </li>
 <li class="listitem">
 <p>most navigations of an operation or property from a null source </p>
 </li>
 </ul>
 </div>
 <p>In this tutorial we will show how to eliminate the hazards of unsafe navigation from null.</p>
 </div>
 <div class="section" title="Enable Safe Navigation Diagnosis">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="EnableSafeNavigationDiagnosis"></a>Enable Safe Navigation Diagnosis</h3>
 </div>
 </div>
 </div>
 <p>Safe navigation is too new and experimental to be enabled by default. You must therefore enable it
 					explicitly by selecting the
 					<span class="bold"><strong>OCL-&gt;Unified Pivot Binding</strong></span> settings from the workspace
 					<span class="bold"><strong>Window-&gt;Preferences</strong></span>. You may
 					alternatively set project-specific preferences from Project property pages.
 				</p>
 <p>Change the
 					<span class="bold"><strong>Potential null navigation</strong></span> and
 					<span class="bold"><strong>Redundant safe navigation</strong></span> to
 					<span class="bold"><strong>Error</strong></span> (or warning).
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4120-safe-navigation-preferences.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Safe Navigation Diagnosis">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="SafeNavigationDiagnosis"></a>Safe Navigation Diagnosis</h3>
 </div>
 </div>
 </div>
 <p>We will continue the OCLinEcore tutorial, which you may jump to the end of by
 					<span class="bold"><strong>New -&gt;Example... -&gt;OCL Plugins -&gt;OCLinEcore Tutorial</strong></span>.
 				</p>
 <p>Select
 					<span class="bold"><strong>Tutorial.ecore</strong></span> and open with the
 					<span class="bold"><strong>OCLinEcore Editor</strong></span>. 8 errors appear on 5 lines.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4120-raw-safe-navigation-errors.png"></div>
 <p>

 </p>
 <p>A bit depressing; 5 out of 7 OCL lines have hazards on a long standing example. The problems arise wherever a null is permitted.</p>
 <p>Non-collection values may be null whenever the multiplicity is implicitly or explicitly
 					<span class="bold"><strong>MyType[?]</strong></span>, which permits either an instance of MyType or null. The alternative
 					<span class="bold"><strong>MyType[1]</strong></span> prohibits a null value. The example metamodel is comparatively good with many properties such as
 					<span class="bold"><strong>Loan::book</strong></span> defined as as
 					<span class="bold"><strong>Book[1]</strong></span>. However
 					<span class="bold"><strong>Loan::date</strong></span> is
 					<span class="bold"><strong>Date[?]</strong></span> which seems unwise; why should a Loan have an unknown Date?
 					<span class="bold"><strong>Book::library</strong></span> is correctly
 					<span class="bold"><strong>Library[?]</strong></span> since there is no reason why Books may not found in Bookshops or Homes.
 				</p>
 <p>We will examine the two errors after expanding short forms.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4120-expanded-safe-navigation-error.png"></div>
 <p>

 </p>
 <p>

 <code class="code">self.library.loans</code> violates the UnsafeSourceCannotBeNull constraint because the source,
 					<code class="code">self.library</code>, can be null as a consequence of the
 					<span class="bold"><strong>library[?]</strong></span> multiplicity.
 				</p>
 <p>Collection values, which are almost the raison d&rsquo;etre of OCL, are a disaster safe-navigation-wise. Any OCL collection may contain a null value and so any OCL iteration may have a null iterator. Consequently the implicit iterator is typed as
 					<span class="bold"><strong>Loan[?]</strong></span> and the source of
 					<code class="code">loan.book</code> is also unsafe.
 				</p>
 </div>
 <div class="section" title="Safe Navigation Operators">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="SafeNavigationOperators"></a>Safe Navigation Operators</h3>
 </div>
 </div>
 </div>
 <p>Languages such as Groovy have introduced a safe navigation operator to mitigate problems with null navigation. It is proposed that OCL 2.5 will do so too. Eclipse OCL provides a prototype implementation.</p>
 <p>OCL provides two navigation operators</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>the object navigation operator "."</p>
 </li>
 <li class="listitem">
 <p>the collection navigation operator "-&gt;".</p>
 </li>
 </ul>
 </div>
 <p>Safe navigation adds</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>the safe object navigation operator "?."</p>
 </li>
 <li class="listitem">
 <p>the safe collection navigation operator "?-&gt;".</p>
 </li>
 </ul>
 </div>
 <p>The safe object navigation operator replaces any null navigation by
 					<code class="code">null</code>. Where
 					<code class="code">a</code> is an object value,
 					<code class="code">a?.b</code> is therefore equivalent to
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">let&nbsp;a'&nbsp;=&nbsp;a&nbsp;in&nbsp;if&nbsp;a'&nbsp;&lt;&gt;&nbsp;null&nbsp;then&nbsp;a'.b&nbsp;else&nbsp;null&nbsp;endif<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The safe collection navigation operator eliminates all null terms from collection sources.
 					<code class="code">a?-&gt;b</code> is therefore equivalent to
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">a-&gt;excluding(null)-&gt;b<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The safe implicit collection navigation operator similarly eliminates all null terms from collection. Where
 					<code class="code">a</code> is a collection value,
 					<code class="code">a.b</code> is therefore equivalent to
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">a-&gt;excluding(null)-&gt;collect(b)<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>We may use these operators to make the warnings go away.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4120-suppressed-safe-navigation-error.png"></div>
 <p>

 </p>
 <p>The first replacement for
 					<code class="code">library?.loans</code> is reasonable. The
 					<code class="code">library</code> really can be
 					<code class="code">null</code> and so, if it is null, the shortform execution is
 					<code class="code">null-&gt;select(book = self)</code>. Use of a collection operator on a non-collection object such as
 					<code class="code">null</code> causes oclAsSet() to be invoked which for
 					<code class="code">null</code> gives giving an empty set. Therefore
 					<code class="code">null.oclAsSet()-&gt;select(...)</code> selects elements from an empty set ensuring that the loans from a null library are an empty collection.
 				</p>
 <p>The second replacement for
 					<code class="code">loans?-&gt;select</code> makes the problem go away, but in practice requires almost every collection navigation operator to be prefixed lexically by &ldquo;?&rdquo; and operationally by an
 					<code class="code">exclude(null)</code>.
 				</p>
 </div>
 <div class="section" title="Null-free Collections">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="NullfreeCollections"></a>Null-free Collections</h3>
 </div>
 </div>
 </div>
 <p>OCL and UML support four permutations of ordered/not-ordered, unique/not-unique to give useful Collection behaviors.</p>
 <p>OCL unfortunately allows any collection to contain null, even though null collection elements are undesirable in almost
 					all applications, and as we have just seen safe, navigation imposes a redundant
 					<code class="code">exclude(null)</code> on many collection accesses.
 				</p>
 <p>The need for
 					<code class="code">exclude(null)</code> can be eliminated if OCL collections can be declared to be null-free, potentially giving 8 rather than 4 possible collection behaviors.
 				</p>
 <p>UML and Ecore declarations of collections such as
 					<code class="code">MyType[2..*] {ordered}</code> support bounds, whereas Complete OCL supports nested collections such as
 					<code class="code">Set(Sequence(MyType))</code>. UML alignment for OCL 2.5 supports nested bounded collections such as
 					<code class="code">Set(Sequence(MyType[*])[+])</code>; a Set of one or more Sequences of zero or more MyTypes.
 				</p>
 <p>We can extend this notation by suffixing an element multiplicity following each collection multiplicity so that each element may be</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>non-null, explicitly
 							<code class="code">[...|1]</code>

 </p>
 </li>
 <li class="listitem">
 <p>implicitly or explicitly null/not-null
 							<code class="code">[...|?]</code>

 </p>
 </li>
 </ul>
 </div>
 <p>It is not useful to have
 					<code class="code">null</code> loans so we can change the multiplicity of
 					<code class="code">Library::loans</code> to
 					<code class="code">Loan[*|1]</code>; zero or more Loan objects where each loan is not-null.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4120-null-free-collection-suppression.png"></div>
 <p>

 </p>
 <p>The problem with the iterator is now replaced by one with the iteration. The SafeSourceCanBeNull constraint is now violated because the source
 					<code class="code">library?.loan</code> cannot provide null elements as a consequence of the
 					<span class="bold"><strong>[==</strong></span>|1==]* multiplicity. Note that the extended multiplicity is shown in messages and hover text to assist in understanding null-ness.
 				</p>
 <p>Revert back to
 					<code class="code">loans-&gt;select</code> and the new problem goes away; changing the multiplicity to declare a null-free collection makes the original expression safe without an additional safe navigation operator.
 				</p>
 </div>
 <div class="section" title="Declaring Null-free Collections in Ecore">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="DeclaringNullfreeCollectionsinEcore"></a>Declaring Null-free Collections in Ecore</h3>
 </div>
 </div>
 </div>
 <p>We have just seen an extension to the multiplicity syntax so that in OCLinECore a null-free collection may be declared by the
 					<span class="bold"><strong>[...|1]</strong></span> extended per-element multiplicity.
 				</p>
 <p>Ecore does not support null-free collections and so behind the scenes this is represented by an EAnnotation.</p>
 <div class="literallayout">
 <p>
 <code class="code">&nbsp;&nbsp;&nbsp;&nbsp;&lt;eStructuralFeatures&nbsp;xsi:type="ecore:EReference"&nbsp;name="loans"&nbsp;ordered="false"<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;upperBound="-1"&nbsp;eType="#//Loan"&nbsp;containment="true"&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;eAnnotations&nbsp;source="http://www.eclipse.org/OCL/Collection"&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;details&nbsp;key="nullFree"&nbsp;value="true"/&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/eAnnotations&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&lt;/eStructuralFeatures&gt;<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 <div class="section" title="Declaring Null-free Collections in UML">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="DeclaringNullfreeCollectionsinUML"></a>Declaring Null-free Collections in UML</h3>
 </div>
 </div>
 </div>
 <p>UML does not support null-free collections and so an OCLforUML profile is introduced to remedy this and other deficiencies.</p>
 <p>A
 					<span class="bold"><strong>Collection</strong></span> stereotype may be applied to a
 					<span class="bold"><strong>TypedElement</strong></span> such as a
 					<span class="bold"><strong>Parameter</strong></span> or
 					<span class="bold"><strong>Property</strong></span> so that the
 					<code class="code">Collection::isNullFree</code> property defines the required null-free-ness.
 				</p>
 <p>Applying a stereotype to all collection properties and parameters is a little tedious and may be avoided by instead applying the
 					<span class="bold"><strong>Collections</strong></span> stereotype to
 					<span class="bold"><strong>Class</strong></span>es or even
 					<span class="bold"><strong>Package</strong></span>s. The null-free-ness is determined by looking first for a
 					<span class="bold"><strong>Collection</strong></span> stereotype, then searching the container hierarchy for the nearest
 					<span class="bold"><strong>Collections</strong></span> stereotype.
 				</p>
 <p>A single
 					<span class="bold"><strong>Collections</strong></span> stereotype application on a
 					<span class="bold"><strong>Package</strong></span> is sufficient to declare all its collections null-free This is often appropriate, however if any collections can contain nulls, the package-level
 					<span class="bold"><strong>Collections</strong></span> stereotype must be overridden for each
 					<span class="bold"><strong>TypedElement</strong></span> where the collection may contain a null.
 				</p>
 </div>
 </div>
 <div class="section" title="Code Generation tutorial">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="CodeGenerationTutorial"></a>Code Generation tutorial</h2>
 </div>
 </div>
 </div>
 <p>This tutorial has been updated for Eclipse Mars: Eclipse 4.5, EMF 2.11, OCL 6.0.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Some screenshots may be slightly out of date.</p>
 </li>
 </ul>
 </div>
 <p>The direct OCL to Java Code generator was a very experimental functionality for the Juno release. It has been substantially rewritten for Kepler. Some optimisations have been activated for Luna and Mars. </p>
 <p>In this tutorial we will continue the OCLinEcore tutorial and show how to get a direct Java representation of the Ecore model avoiding the need for run-time compilation.</p>
 <div class="section" title="Load OCLinEcore Tutorial Example Project">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="LoadOCLinEcoreTutorialExampleProject"></a>Load OCLinEcore Tutorial Example Project</h3>
 </div>
 </div>
 </div>
 <p>All the material for this tutorial is available as part of the OCLinEcore Example project that you
 					may load by selecting
 					<span class="bold"><strong>New</strong></span> then
 					<span class="bold"><strong>Example...</strong></span> using the right button context menu of the Project Explorer. This
 					should give the
 					<span class="bold"><strong>New Example</strong></span> dialog in which you can select the
 					<span class="bold"><strong>OCL (OCL Constraint Language) Plugins</strong></span> and the
 					<span class="bold"><strong>OCLinEcore Tutorial</strong></span>.
 				</p>
 </div>
 <div class="section" title="Direct code">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Directcode"></a>Direct code</h3>
 </div>
 </div>
 </div>
 <p>In
 					<a class="link" href="#OCLinEcoreTutorial-genmodel" title="Generating Java Code">Generating Java Code</a> we saw how to create a genmodel and how to generate code from it that realizes OCL as text strings in the Java implementation files. These text strings are lazily compiled at run-time.
 				</p>
 <p>Whether to generate OCL as text strings for interpretation or to convert directly to Java is determined by the Code Generation Mode. This may be configured using  the project property or workspace preference as described in
 					<a class="link" href="#CodeGenerationMode" title="Code Generation Mode">Code Generation Mode</a>. So use
 					<span class="bold"><strong>Window-&gt;Preferences-&gt;OCL</strong></span> to change the
 					<span class="bold"><strong>Realisation of OCL embedded in Ecore models</strong></span> setting to
 					<span class="bold"><strong>Generate Java code in *Impl classes</strong></span>.
 				</p>
 <p>Now open
 					<span class="bold"><strong>Tutorial.genmodel</strong></span>, select the root resource and invoke
 					<span class="bold"><strong>Generate Model Code</strong></span> to (re)generate the Java code. This will take somewhat longer as additional work items show that the OCL is being compiled and that Xtend templates are generating additional Java code.
 				</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						Note that you must close
 						<span class="bold"><strong>Tutorial.genmodel</strong></span> while changing the Code Generation Mode.
 					</p>
 <p>You may also need to delete the autogenerated *Impl files if you change from one mode of generation to another.</p>
 </blockquote>
 </div>
 <p></p>
 <p>That is all there is to it. Your model code is now 100% Java; no OCL parsing is needed at run-time. </p>
 </div>
 <div class="section" title="Using a GenAnnotation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="UsingaGenAnnotation"></a>Using a GenAnnotation</h3>
 </div>
 </div>
 </div>
 <p>Changing the default genmodel setting is a little dangerous since the change will affect any other genmodel activities you perform. It is therefore advisable to reset the workspace preference setting to its default and use a GenAnnotation to embed the setting in the genmodel.</p>
 <p>The easiest way to create the GenAnnotation that ensure direct code generation regardless of workspace or project preferences, is to paste the following three lines into your genmodel just above the
 					<code class="code">foreignModel</code> or
 					<code class="code">genpackages</code> element.
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">&nbsp;&nbsp;&lt;genAnnotations&nbsp;source="http://www.eclipse.org/OCL/GenModel"&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&lt;details&nbsp;key="Use&nbsp;Delegates"&nbsp;value="false"/&gt;<br>
 &nbsp;&nbsp;&lt;/genAnnotations&gt;<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>Of course, if you want to enforce delegation you should set the
 					<code class="code">value</code> to
 					<code class="code">true</code>.
 				</p>
 <p>If you don&rsquo;t like cutting and pasting into XMI files, you can achieve the same effect with the GenModel editor by:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Enable annotation display using
 							<span class="bold"><strong>Generator-&gt;Show Annotations</strong></span>

 </p>
 </li>
 <li class="listitem">
 <p>Invoke
 							<span class="bold"><strong>Annotate</strong></span> from the right button context menu of the genmodel root element
 						</p>
 </li>
 <li class="listitem">
 <p>Use the
 							<span class="bold"><strong>Properties View</strong></span> to set the GenAnnotation source to
 							<code class="code">http://www.eclipse.org/OCL/GenModel</code>

 </p>
 </li>
 <li class="listitem">
 <p>Invoke
 							<span class="bold"><strong>Add Detail</strong></span> from the right button context menu of the GenAnnotation
 						</p>
 </li>
 <li class="listitem">
 <p>Use the
 							<span class="bold"><strong>Properties View</strong></span> to set the Detail key to
 							<code class="code">Use Delegates</code>

 </p>
 </li>
 <li class="listitem">
 <p>Use the
 							<span class="bold"><strong>Properties View</strong></span> to set the Detail value to
 							<code class="code">false</code>

 </p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4400-genannotation.png"></div>
 <p>

 </p>
 <p>A further
 					<span class="bold"><strong>Use Null Annotations</strong></span> GenAnnotation may be used to control whether @NonNull and @Nullable annotations are emitted in the generated code.
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">&nbsp;&nbsp;&lt;genAnnotations&nbsp;source="http://www.eclipse.org/OCL/GenModel"&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&lt;details&nbsp;key="Use&nbsp;Delegates"&nbsp;value="false"/&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&lt;details&nbsp;key="Use&nbsp;Null&nbsp;Annotations"&nbsp;value="true"/&gt;<br>
 &nbsp;&nbsp;&lt;/genAnnotations&gt;<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 </div>
 <div class="section" title="Debugger tutorial">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="DebuggerTutorial"></a>Debugger tutorial</h2>
 </div>
 </div>
 </div>
 <p>This tutorial has been updated for Eclipse Mars: Eclipse 4.5, EMF 2.11, OCL 6.0.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Some screenshots may be slightly out of date.</p>
 </li>
 </ul>
 </div>
 <p>In this tutorial we will continue the
 				<a class="link" href="#OCLinEcoreTutorial" title="OCLinEcore tutorial">OCLinEcore tutorial</a> and show how to use the
 				<a class="link" href="#Debugger" title="Debugger (new in Luna)">OCL debugger</a> to debug:
 			</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>constraints typed manually in the Console View</p>
 </li>
 <li class="listitem">
 <p>embedded OCLinEcore validation failures from the Validity View</p>
 </li>
 <li class="listitem">
 <p>Complete OCL validation failures from the Validity View</p>
 </li>
 </ul>
 </div>
 <div class="section" title="Load OCLinEcore Tutorial Example Project">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="LoadOCLinEcoreTutorialExampleProject2"></a>Load OCLinEcore Tutorial Example Project</h3>
 </div>
 </div>
 </div>
 <p>The material for the first two parts of this tutorial is available as part of the OCLinEcore Example project that you
 					may load by selecting
 					<span class="bold"><strong>New</strong></span> then
 					<span class="bold"><strong>Example...</strong></span> using the right button context menu of the Project Explorer. This
 					should give the
 					<span class="bold"><strong>New Example</strong></span> dialog in which you can select the
 					<span class="bold"><strong>OCL (OCL Constraint Language) Plugins</strong></span> and the
 					<span class="bold"><strong>OCLinEcore Tutorial</strong></span>.
 				</p>
 <p>The material for the third parts of this tutorial is available as part of the CompleteOCL Example project that you
 					may load in a similar way.</p>
 </div>
 <div class="section" title="The OCL Debugger">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheOCLDebugger"></a>The OCL Debugger</h3>
 </div>
 </div>
 </div>
 <p>The OCL debugger is a customization of the Eclipse debugger framework, so most of its functionality should present few surprises to those familiar with the Java debugger.</p>
 <p>There is:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>a Stack View that shows the current line number in nested Evaluation Environments</p>
 </li>
 <li class="listitem">
 <p>a Variables View in which local and intermediate variables can be re-examined</p>
 </li>
 <li class="listitem">
 <p>an Editor in which the source is highlighted to show the next AST node to be evaluated</p>
 </li>
 <li class="listitem">
 <p>an Outline in which the source is shown in tree form</p>
 </li>
 <li class="listitem">
 <p>a Breakpoints View in which breakpoints can be controlled</p>
 </li>
 </ul>
 </div>
 <p>We will demonstrate some of these facilities by debugging a simple example.</p>
 </div>
 <div class="section" title="Very Simple Debug session">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="VerySimpleDebugsession"></a>Very Simple Debug session</h3>
 </div>
 </div>
 </div>
 <p>We will debug the execution of the OCL expression
 					<span class="bold"><strong>self.name</strong></span> on an EPackage.
 				</p>
 <div class="section" title="Starting the debugger">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Startingthedebugger"></a>Starting the debugger</h4>
 </div>
 </div>
 </div>
 <p>Double click on
 						<span class="bold"><strong>model/Tutorial.ecore</strong></span> to open the model and expand the top entry to show the EPackage.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-simple-debugger-model.png"></div>
 <p>

 </p>
 <p>If the model opens with another editor, close it, and open with the Sample Ecore Editor by selecting
 						<span class="bold"><strong>model/Tutorial.ecore</strong></span> and then
 						<span class="bold"><strong>Open With-&gt;Sample Ecore Model Editor</strong></span> from the context menu.
 					</p>
 <p>Select the
 						<span class="bold"><strong>tutorial</strong></span> EPackage and invoke
 						<span class="bold"><strong>OCL-&gt;Show Xtext OCL Console</strong></span> from the context menu. (Wait a second or two.)
 					</p>
 <p>At the bottom of the Console window type
 						<span class="bold"><strong>self.name</strong></span>, then hit the Enter key. Then hit the Page Up key to redisplay your entry.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-simple-debugger-input.png"></div>
 <p>

 </p>
 <p>The Console runs an evaluation automatically after hitting Enter and shows the evaluation result:
 						<span class="bold"><strong>'tutorial'</strong></span>.
 					</p>
 <p>The Console View provides the two pieces of information necessary to run the OCL debugger:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>an EObject to be used as OCL&rsquo;s
 								<span class="bold"><strong>self</strong></span>; the Console shows the current selection just below its tool bar
 							</p>
 </li>
 <li class="listitem">
 <p>an OCL expression to execute</p>
 </li>
 </ul>
 </div>
 <p>Start the debugger by clicking the debug icon in the Console View tool bar. (Wait a second or two.)</p>
 <p>The debugger perspective should appear automatically. If it doesn&rsquo;t, you can open the Debug perspective manually by invoking
 						<span class="bold"><strong>Window-&gt;Perspective-&gt;Open Perspective-&gt;Debug</strong></span> from the Eclipse menu bar.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-simple-debugger-image.png"></div>
 <p>

 </p>
 <p>A Complete OCL document is created automatically to encapsulate the OCL expression inside as an additional operation for the type of the
 						<span class="bold"><strong>self</strong></span> object. This document is shown in the editor; it is readonly.
 					</p>
 <p>The stack display shows the context as line 5 of
 						<span class="bold"><strong>oclDebugExpression()</strong></span> in the synthesized Complete OCL document.
 					</p>
 <p>Select the
 						<span class="bold"><strong>oclDebugExpression()</strong></span> line in the stack display;
 						<span class="bold"><strong>self</strong></span> is highlighted in the Complete OCL document, since the next evaluation to perform is to evaluate the VariableExp AST node that performs the self access.
 					</p>
 <p>The Variables View shows two variables.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <span class="bold"><strong>self</strong></span> is the OCL self object
 							</p>
 </li>
 <li class="listitem">
 <p>

 <span class="bold"><strong>$pc</strong></span> is a synthetic variable representing the current Program Counter
 							</p>
 </li>
 </ul>
 </div>
 <p>The Outline View displays a slightly trimmed OCL Abstract Syntax tree; you may choose to close this view. In a future release it may change to support breakpoints. The view shows</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>an
 								<span class="bold"><strong>Import</strong></span> for
 								<span class="bold"><strong>ecore</strong></span>

 </p>
 </li>
 <li class="listitem">
 <p>a
 								<span class="bold"><strong>Class</strong></span> named
 								<span class="bold"><strong>EPackage</strong></span> containing
 							</p>
 </li>
 <li class="listitem">
 <p>an
 								<span class="bold"><strong>Operation</strong></span> named
 								<span class="bold"><strong>oclDebugExpression</strong></span> containing
 							</p>
 </li>
 <li class="listitem">
 <p>an
 								<span class="bold"><strong>ExpressionInOCL</strong></span> whose
 								<span class="bold"><strong>OwnedBody</strong></span> is a
 								<span class="bold"><strong>PropertyCallExp</strong></span> for
 								<span class="bold"><strong>name</strong></span> and whose source is
 							</p>
 </li>
 <li class="listitem">
 <p>a
 								<span class="bold"><strong>VariableExp</strong></span> for
 								<span class="bold"><strong>self</strong></span>.
 							</p>
 </li>
 </ul>
 </div>
 <p>The outline shows fuller type signatures to assist in debugging.</p>
 </div>
 <div class="section" title="Exploring Variables">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ExploringVariables"></a>Exploring Variables</h4>
 </div>
 </div>
 </div>
 <p>The Variables View provides an ability to drill down arbitrarily to examine the data available to your program.</p>
 <p>The left column of the display presents the name of a variable and may be expanded to navigate to parts of the data referenced by the variable. Part name displays are currently shown 0-based, rather than 1-based as in OCL. </p>
 <p>The right column variously displays the type of parts that can be expanded and the values of those that cannot. An OCL syntax is used so Strings appear in single quotes and Collections use names such as OrderedSet. </p>
 <p>The bottom line shows a textual rendering of the selected variable. For many types of data a helpful rendering is available. For others the fallback is to the default Java toString() functionality. The text can be customized by</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>the
 								<span class="bold"><strong>org.eclipse.ocl.pivot.utilities.getText()</strong></span> method if the object implements
 								<span class="bold"><strong>Labelable</strong></span>

 </p>
 </li>
 <li class="listitem">
 <p>the
 								<span class="bold"><strong>LabelUtil.QUALIFIED_NAME_REGISTRY</strong></span> if an
 								<span class="bold"><strong>org.eclipse.ocl.pivot.label_generator</strong></span> extension point has a registration for the objects' class
 							</p>
 </li>
 </ul>
 </div>
 <p>Click on the expand/collapse icon to the left of
 						<span class="bold"><strong>$pc</strong></span> to expand it and allow inspection of the OCL AST. A VariableExp is next to execute and its
 						<span class="bold"><strong>$pc.referredProperty</strong></span> or
 						<span class="bold"><strong>$pc.type</strong></span> may be examined to see more program detail.
 					</p>
 <p>Click on the expand/collapse icon to the left of
 						<span class="bold"><strong>self</strong></span>, which is an
 						<span class="bold"><strong>ecore::EPackage</strong></span>, to expand it and shows its fields such as
 						<span class="bold"><strong>name</strong></span> which is
 						<span class="bold"><strong>'tutorial'</strong></span>.
 					</p>
 <p>Click on the expand/collapse icon to the left of
 						<span class="bold"><strong>self.eClassifiers</strong></span> to show the four classifiers.
 					</p>
 <p>Select
 						<span class="bold"><strong>self.eClassifiers[ 1 ]</strong></span> so that the bottom line display shows that the second is named Book.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-simple-debugger-image.png"></div>
 <p>

 </p>
 <p>The Variables View provides more insight that the Sample Ecore Properties View, so you may find it convenient to use a trivial OCL debugger session using
 						<span class="bold"><strong>self</strong></span> as the OCL expression to browse arbitrary model data.
 					</p>
 </div>
 <div class="section" title="Stepping Execution">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="SteppingExecution"></a>Stepping Execution</h4>
 </div>
 </div>
 </div>
 <p>Click F5 or the
 						<span class="bold"><strong>Step Into</strong></span> icon to advance execution by one AST node evaluation.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-simple-debugger-step1.png"></div>
 <p>

 </p>
 <p>The editor now highlights
 						<span class="bold"><strong>.name</strong></span>;
 						<span class="bold"><strong>$pc</strong></span> shows a PropertCallExp as the next execution.
 						<span class="bold"><strong>$pc.referredProperty</strong></span> shows that it is
 						<span class="bold"><strong>ecore::ENamedElement:name</strong></span>.
 					</p>
 <p>An additional synthetic variable
 						<span class="bold"><strong>$owwnedSource</strong></span> shows the result of the
 						<span class="bold"><strong>self</strong></span> evaluation that forms the source term of the PropertyCallExp. As expected this is the same as
 						<span class="bold"><strong>self</strong></span>.
 					</p>
 <p>Click F5 or the
 						<span class="bold"><strong>Step Into</strong></span> icon again to advance execution by a further AST node evaluation.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-simple-debugger-step2.png"></div>
 <p>

 </p>
 <p>The whole of
 						<span class="bold"><strong>self.name</strong></span> is highlighted and
 						<span class="bold"><strong>$pc</strong></span> shows that the overall ExpressionInOCL is about to be evaluated. The synthetic
 						<span class="bold"><strong>$ownedBody</strong></span> for its input shows that
 						<span class="bold"><strong>self.name</strong></span> evaluated to
 						<span class="bold"><strong>'tutorial'</strong></span>.
 					</p>
 </div>
 </div>
 <div class="section" title="Debugging a Validation failure">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="DebuggingaValidationfailure"></a>Debugging a Validation failure</h3>
 </div>
 </div>
 </div>
 <p>OCL is useful for elaborating models with additional well-formedness rules, but when these fail it can be difficult to understand why a failure occurred, particularly if the bug is in the OCL rather than the model. We will now show how the OCL debugger can be used to debug a validation failure.</p>
 <p>Double click on
 					<span class="bold"><strong>model/Tutorial.xmi</strong></span> to open the model, and expand the top two entries to show some detail.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-validation-debugger-model.png"></div>
 <p>

 </p>
 <p>If the model opens with another editor, close it, and open with the Sample Reflective Ecore Model Editor by selecting
 					<span class="bold"><strong>model/Tutorial.xmi</strong></span> and then
 					<span class="bold"><strong>Open With-&gt;Sample Reflective Ecore Model Editor</strong></span> from the context menu.
 				</p>
 <p>Select the first line and invoke
 					<span class="bold"><strong>Validate</strong></span> from the context menu. (Wait a second.) Optionally click on Details.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-validation-debugger-errors.png"></div>
 <p>

 </p>
 <p>These error messages provide insufficient precision to really understand the problems, so click
 					<span class="bold"><strong>OK</strong></span> to dismiss the popup then select
 					<span class="bold"><strong>Book b2</strong></span>, which has an error, and invoke
 					<span class="bold"><strong>OCL-&gt;Show Validity View</strong></span> to provide more insight.
 				</p>
 <p>If the Validity View shows question marks rather than red/green/amber status decorations, Click the Run icon in the Validity View tool bar.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-validation-debugger-vv1.png"></div>
 <p>

 </p>
 <p>Click the
 					<span class="bold"><strong>Pin</strong></span> icon in the Validity View tool bar to avoid thrashing whenever you change mouse selection.
 				</p>
 <p>Uncheck the top
 					<span class="bold"><strong>ecore</strong></span> line in the Metamodel Constraints since we are not interested in the successful Ecore metamodel constraints just those in the
 					<span class="bold"><strong>tutorial</strong></span> metamodel.
 				</p>
 <p>Similarly uncheck the bottom
 					<span class="bold"><strong>tutorial</strong></span> line in the Model Elements since we are not interested in the successful metamodel, just those in the tutorial model.
 				</p>
 <p>Click on the + tool bar icon so that the detail is shown.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-validation-debugger-vv2.png"></div>
 <p>

 </p>
 <p>We will now debug the failure of the
 					<span class="bold"><strong>tutorial::Book::SufficientCopies</strong></span> on the
 					<span class="bold"><strong>Library lib::Book b2</strong></span> model element. Select either of the leaf warnings, that is either the
 					<span class="bold"><strong>tutorial::Book::SufficientCopies</strong></span> child of
 					<span class="bold"><strong>Book b2</strong></span> in the left hand pane, or the
 					<span class="bold"><strong>Library lib::Book b2</strong></span> child of
 					<span class="bold"><strong>SufficientCopies</strong></span> in the right hand pane, and invoke
 					<span class="bold"><strong>Debug Single Enabled Selection</strong></span>. Wait a second or two and the debugger starts. If it doesn&rsquo;t, open the Debugger perspective manually.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-validation-debugger-image.png"></div>
 <p>

 </p>
 <p>Select the
 					<span class="bold"><strong>oclDebuggerExpression()</strong></span> stack line.
 					The debugger shows
 					<span class="bold"><strong>library.loans-&gt;select((book = self))-&gt;size() &lt;= copies</strong></span> with
 					<span class="bold"><strong>l</strong></span> highlighted as the next execution.
 					The outline shows that the
 					<span class="bold"><strong>VariableExp</strong></span> for
 					<span class="bold"><strong>self</strong></span> is next to execute. The
 					<span class="bold"><strong>library</strong></span> in the source code is a shorthand for
 					<span class="bold"><strong>self.library</strong></span>
 					so highlighting
 					<span class="bold"><strong>l</strong></span> is an approximation to highlighting the invisible
 					<span class="bold"><strong>source.</strong></span> in front of
 					<span class="bold"><strong>library</strong></span>.

 					<span class="bold"><strong>$pc</strong></span> in the Variables View also shows a VariableExp for self as the next instruction.
 				</p>
 <p>Click F5 or
 					<span class="bold"><strong>Step Into</strong></span> and
 					<span class="bold"><strong>$pc</strong></span> advances and the editor highlight changes to
 					<span class="bold"><strong>library</strong></span>.
 				</p>
 <p>Click F5 or
 					<span class="bold"><strong>Step Into</strong></span> a few more times and the highlight will show the iteration within the
 					<span class="bold"><strong>select</strong></span> body, allowing each state of each element to be examined to determine why the exhibited behavior occurs.
 				</p>
 <p>Continue to Click F5 or
 					<span class="bold"><strong>Step Into</strong></span> until
 					<span class="bold"><strong>-&gt;size()</strong></span> is highlighted.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-validation-debugger-step1.png"></div>
 <p>

 </p>
 <p>Expanding
 					<span class="bold"><strong>$ownedSource</strong></span> in the Variables View shows the Set of three selected Loans each of which has the same book as self.
 				</p>Click F5 or
 				<span class="bold"><strong>Step Into</strong></span> three more times until
 				<span class="bold"><strong>&lt;=</strong></span> is highlighted.
 				<p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-validation-debugger-step2.png"></div>
 <p>

 </p>
 <p>We can now see that the
 					<span class="bold"><strong>$ownedSource</strong></span>, left hand side, of the comparison is 3 and the
 					<span class="bold"><strong>$ownedArguments[0]</strong></span> right hand side is 2.
 					A further step and we see the result as
 					<span class="bold"><strong>$ownedBody</strong></span> demonstrating why the validation failed.
 				</p>
 </div>
 <div class="section" title="Debugging Complete OCL validation failure">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="DebuggingCompleteOCLvalidationfailure"></a>Debugging Complete OCL validation failure</h3>
 </div>
 </div>
 </div>
 <p>The two preceding examples displayed their source text in a synthesized Complete OCL document.</p>
 <p>In this example we debug a failure for which the OCL is already available in a Complete OCL document.</p>
 <p>Open the
 					<span class="bold"><strong>model/EcoreTestFile.ecore</strong></span> from the
 					<a class="link" href="#CompleteOCLTutorial" title="Complete OCL tutorial">Complete OCL tutorial</a> project using the Sample Ecore Editor.
 				</p>
 <p>Within the Ecore editor use
 					<span class="bold"><strong>OCL-&gt;Load Document</strong></span> and then drag and drop
 					<span class="bold"><strong>model/ExtraEcoreValidation.ocl</strong></span> and click
 					<span class="bold"><strong>OK</strong></span> to dismiss the pop up.
 				</p>
 <p>Again within the Ecore editor use
 					<span class="bold"><strong>OCL-&gt;Show Validity View</strong></span> to see the constraint/element pairs.
 					<span class="italic">If the Validity View was already visible, close it and re-show it since in Mars addition of a Complete OCL document fails to refresh correctly.</span>

 </p>
 <p>In the Validity View, uncheck the
 					<span class="bold"><strong>ecore</strong></span> Metamodel Constraint contributions retaining just the
 					<span class="bold"><strong>ExtraEcoreValidation.ocl</strong></span> contribution. Click the plus icon in the
 					<span class="bold"><strong>Metamodel Constraint</strong></span> tool bar to expand all entries.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-complete-ocl-debugger-model.png"></div>
 <p>

 </p>
 <p>Select the bottom right
 					<span class="bold"><strong>BadClass</strong></span> model element below the
 					<span class="bold"><strong>DerivationIsVolatile</strong></span> constraint and invoke
 					<span class="bold"><strong>Debug Single Enabled Selection</strong></span>. from the context menu (wait a second or two). The debugger should start, if not open the Debugger perspective manually.
 				</p>
 <p>

 <span class="italic">In Mars, select the
 						<span class="bold"><strong>DerivationIsVolatile</strong></span> stack line to refresh the selection.
 					</span>

 </p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4500-complete-ocl-debugger-image.png"></div>
 <p>

 </p>
 <p>Both
 					<span class="bold"><strong>asError</strong></span> and
 					<span class="bold"><strong>hasDerivation</strong></span> are OCL-defined so as you step you successively navigate into the defined property and operation.
 				</p>
 </div>
 <div class="section" title="Console experiments">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Consoleexperiments"></a>Console experiments</h3>
 </div>
 </div>
 </div>
 <p>While debugging, the original OCL expression from the Console is presented in a Complete OCL editor. This editor is readonly so you cannot edit it to correct mistakes or to experiment.</p>
 <p>You may however safely use the OCL Console to perform further experiments. Select a suitable self object in the Variable View and cut and paste to prepare your experimental OCL expression.</p>
 <p>

 <span class="italic">In Mars, Console selections cannot be Collections so you are unfortunately restricted to single objects.</span>

 </p>
 </div>
 <div class="section" title="Longer range stepping">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Longerrangestepping"></a>Longer range stepping</h3>
 </div>
 </div>
 </div>
 <p>In the examples above we have only used F5 or
 					<span class="bold"><strong>Step Into</strong></span>.
 				</p>
 <p>In principle the tedious stepping through an iteration can be avoided by F7 or
 					<span class="bold"><strong>Step Return</strong></span> which should terminate on the popped evaluation environment at the end of the iteration.
 					<span class="italic">This facility has not been adequately tested in Mars</span>.
 				</p>
 <p>If you arrange for some line breaks in your source text you can use F6 or
 					<span class="bold"><strong>Step Next</strong></span> to proceed until the line number advances.
 					<span class="italic">This facility has not been adequately tested in Mars</span>. Line breaks can be added in the OCL Console using Shift and Enter together.
 				</p>
 </div>
 <div class="section" title="Break points">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Breakpoints"></a>Break points</h3>
 </div>
 </div>
 </div>
 <p>When debugging OCL from Complete OCL documents, the original document is a suitable source for the debugger and so line breakpoints can be set.
 					<span class="italic">This facility has not been adequately tested in Mars</span>

 </p>
 </div>
 </div>
 <div class="section" title="Validation tutorial">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="ValidationTutorial"></a>Validation tutorial</h2>
 </div>
 </div>
 </div>
 <p>This tutorial has been updated for Eclipse Mars: Eclipse 4.5, EMF 2.11, OCL 6.0.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Some screenshots may be slightly out of date.</p>
 </li>
 </ul>
 </div>
 <p>The standard EMF validation facilities are very useful for avoiding model errors and work well when the models are correct or at least nearly correct. In this tutorial we show how the
 				<a class="link" href="#ValidityView" title="Validity View (new in Luna)">Validity View</a> can provide greater insight into what works and what doesn&rsquo;t.
 			</p>
 <p>We will show how to</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>identify all constraints applicable to a particular model element</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>show the constraint text</p>
 </li>
 <li class="listitem">
 <p>show the validation status</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>identify all model elements constrained by a particular constraint</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>show the constraint text</p>
 </li>
 <li class="listitem">
 <p>show the validation status</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>filter the displayed model elements and constraints</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>by name</p>
 </li>
 <li class="listitem">
 <p>by status</p>
 </li>
 <li class="listitem">
 <p>by model</p>
 </li>
 <li class="listitem">
 <p>by metamodel</p>
 </li>
 </ul>
 </div>
 </li>
 <li class="listitem">
 <p>launch an OCL debugger for a particular model element and constraint</p>
 </li>
 </ul>
 </div>
 <div class="section" title="Load Complete OCL Tutorial Example Project">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="LoadCompleteOCLTutorialExampleProject2"></a>Load Complete OCL Tutorial Example Project</h3>
 </div>
 </div>
 </div>
 <p>The material for this tutorial is available as part of the Complete OCL Example project that you
 					may load by selecting
 					<span class="bold"><strong>New</strong></span> then
 					<span class="bold"><strong>Example...</strong></span> using the right button context menu of the Project Explorer. This
 					should give the
 					<span class="bold"><strong>New Example</strong></span> dialog in which you can select the OCL (OCL Constraint Language) Plugins and the Complete OCL Tutorial.
 				</p>
 </div>
 <div class="section" title="Load Test Model">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="LoadTestModel"></a>Load Test Model</h3>
 </div>
 </div>
 </div>
 <p>Double click on
 					<span class="bold"><strong>model/XMITestFile.xmi</strong></span> to open the model and expand the top entry to show the EPackage.
 				</p>
 <p>If the model opens with another editor, close it, and open with the Sample Reflective Ecore Editor by selecting
 					<span class="bold"><strong>model/Tutorial.ecore</strong></span> and then
 					<span class="bold"><strong>Open With-&gt;Sample Reflective Ecore Model Editor</strong></span> from the context menu.
 				</p>
 <p>Within the editor invoke
 					<span class="bold"><strong>OCL-&gt;Load Document</strong></span> to load
 					<span class="bold"><strong>model/ExtraEcoreValidation.ocl</strong></span> and again to load
 					<span class="bold"><strong>model/ExtraXMIValidation.ocl</strong></span>

 </p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4600-validation-view-model.png"></div>
 <p>

 </p>
 <p>Your source ResourceSet now contains four resources</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>the XMITestFile.xmi model</p>
 </li>
 <li class="listitem">
 <p>the EcoreTestFile.ecore metamodel</p>
 </li>
 <li class="listitem">
 <p>the ExtraXMIValidation.ocl additional model validation rules</p>
 </li>
 <li class="listitem">
 <p>the ExtraEcoreValidation.ocl additional metamodel validation rules</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="EMF Validation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="EMFValidation"></a>EMF Validation</h3>
 </div>
 </div>
 </div>
 <p>Select the
 					<span class="bold"><strong>XMITestFile.xmi</strong></span> and invoke
 					<span class="bold"><strong>Validate</strong></span> from the context menu. Click
 					<span class="bold"><strong>OK</strong></span> to dismiss.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4600-validation-view-model-errors.png"></div>
 <p>

 </p>
 <p>Select the
 					<span class="bold"><strong>EcoreTestFile.ecore</strong></span> and invoke
 					<span class="bold"><strong>Validate</strong></span> from the context menu. Click
 					<span class="bold"><strong>OK</strong></span> to dismiss.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4600-validation-view-metamodel-errors.png"></div>
 <p>

 </p>
 <p>The above results clearly show problems, but not necessarily all the problems and do not show what was actually done. Sometimes validation of a model element terminates prematurely once an error has been reported. On other occasions some constraints are not run and so no corresponding errors are detected.</p>
 <p>The above limitations are not a problem, when everything is working well, but when you have a misunderstanding as to what is being validated, a bad day can get very much worse.</p>
 <div class="section" title="Validity View Validation">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ValidityViewValidation"></a>Validity View Validation</h4>
 </div>
 </div>
 </div>
 <p>Select
 						<span class="bold"><strong>OCL-&gt;Show Validity View</strong></span> from the editor context menu.
 					</p>
 <p>The left hand pane shows the root model elements in a similar way to the Sample Reflective Ecore Editor.</p>
 <p>The right hand pane shows the root metamodel constraint sources.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4600-validation-view-roots.png"></div>
 <p>

 </p>
 <p>Each may be expanded using the control at the start of each line or the more general controls in the tool bars.</p>
 <p>Important tip: click the pin icon in the Validity Model tool bar to stop the Validity View chasing your mouse selections.</p>
 <p>You may now obtain the more detailed validation results by clicking on the green Run icon in the main Validation View tool bar.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4600-validation-view-root-results.png"></div>
 <p>

 </p>
 <p>Use the hover text to see how many validations have been rounded up into each root display.</p>
 </div>
 <div class="section" title="Filtering by Root Models">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="FilteringbyRootModels"></a>Filtering by Root Models</h4>
 </div>
 </div>
 </div>
 <p>There are 34 results in total, which is more than we want to look at, even for this very small model.</p>
 <p>The
 						<span class="bold"><strong>ecore in http://www.eclipse.org/emf/2002/Ecore</strong></span> root constraint is contributing 30 successes without problem, so we ignore it by unchecking the enable checkbox preceding it.
 					</p>
 <p>The model is so simple that we can now expand it completely. Click on the + expand icons.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4600-validation-view-some-results.png"></div>
 <p>

 </p>
 <p>In the left hand pane, the black text labels show the hierarchy of model elements. At the leaves in blue italic text are the constraints applicable to the model element.</p>
 <p>In the right hand pane, the blue italic labels show the hierarchy of constraints. At the leaves in black text are the constrained model elements.</p>
 <p>You can hover over constraints to see the details and invoke
 						<span class="bold"><strong>Show In Editor</strong></span> to navigate to them.
 					</p>
 </div>
 <div class="section" title="Filtering by Status">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="FilteringbyStatus"></a>Filtering by Status</h4>
 </div>
 </div>
 </div>
 <p>The many successes are often of limited interest, so we may concentrate on Errors by invoking
 						<span class="bold"><strong>Show all Errors</strong></span> from the Filtering pull down towards the right of the main Validation View tool bar.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4600-validation-view-error-results.png"></div>
 <p>

 </p>
 <p>Having found an error of interest we can see it in context.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Select the
 								<span class="bold"><strong>Bad::BadClass::uncachedDerived</strong></span> error in the Constraints pane
 							</p>
 </li>
 <li class="listitem">
 <p>remove the
 								<span class="bold"><strong>Show all Errors</strong></span> filtering using the Filtering pull down
 							</p>
 </li>
 <li class="listitem">
 <p>enable the view of all constraints by clicking the tick icon in the Model Constraint pane tool bar.</p>
 </li>
 </ul>
 </div>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4600-validation-view-results-context.png"></div>
 <p>

 </p>
 <p>This shows that the constraint is validated five times with one error, two warnings and two successes.</p>
 <p>Double clicking on the erroneous child constraint makes the constraint visible in the right hand pane, showing that the constraint is only applied to this one model element.</p>
 </div>
 <div class="section" title="Debugging constraints">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Debuggingconstraints"></a>Debugging constraints</h4>
 </div>
 </div>
 </div>
 <p>Maybe it&rsquo;s time for some debugging. Select the leaf constraint below a model element, or the leaf element below a constraint and invoke
 						<span class="bold"><strong>Debug Single Enabled Selection</strong></span> to start the OCL debugger to step through the problematic constraint on the problematic model element. (Select the debugger perspective explicitly if it doesn&rsquo;t open automatically.)
 					</p>
 <p>Use of the OCL debugger is described in the
 						<a class="link" href="#DebuggerTutorial" title="Debugger tutorial">Debugger Tutorial</a>.
 					</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4600-validation-view-debugger.png"></div>
 <p>

 </p>
 </div>
 </div>
 </div>
 <div class="section" title="Working with Classic OCL">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OCLInterpreterTutorial"></a>Working with Classic OCL</h2>
 </div>
 </div>
 </div>
 <div class="section" title="Overview">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Overview4"></a>Overview</h3>
 </div>
 </div>
 </div>
 <p>This tutorial illustrates the various services provided by the Classic Eclipse OCL
 					implementation.</p>
 </div>
 <div class="section" title="References">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="References3"></a>References</h3>
 </div>
 </div>
 </div>
 <p>This tutorial assumes that the reader is familiar with the Eclipse extension point
 					architecture.  There is an abundance of on-line help in Eclipse for those
 					unfamiliar with extension points.</p>
 <p>To see the complete source code for the examples shown in this tutorial, install
 					the
 					<a class="link" href="#OCLInterpreterExample" title="OCL Interpreter Example">OCL Interpreter Example</a>
 					plug-in into your workspace.
 				</p>
 <p>Other references:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>For an environment in which to test the OCL expressions that you will create in this tutorial, install the
 							<a class="ulink" href="../references/examples/exampleOverview.html" target="_new">Library Metamodel</a> example.
 						</p>
 </li>
 <li class="listitem">
 <p>

 <a class="ulink" href="http://www.omg.org/spec/OCL" target="_new">OCL 2.0</a> specification.
 						</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Parsing OCL Expressions">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ParsingOCLExpressions"></a>Parsing OCL Expressions</h3>
 </div>
 </div>
 </div>
 <p>The first responsibility of the OCL interpreter is to parse OCL expressions.
 					One of the purposes of parsing an expression is to validate it:  if it can be
 					parsed, it is well-formed (the parser automatically validates the expression
 					against the semantic well-formedness rules).</p>
 <p>The main entrypoint into the OCL API is the
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/OCL.html" target="_new">OCL</a> class. An
 					<code class="code">OCL</code> provides an autonomous OCL parsing environment.  It tracks all constraints that are parsed in this environment, including the definitions of additional operations and attributes. The
 					<code class="code">OCL.newInstance()</code> factory method is used to create a new OCL with an
 					<code class="code">EnvironmentFactory</code> that provides the binding to a particular metamodel (Ecore or UML).  In this tutorial, we will use the Ecore binding.
 				</p>
 <p>To parse a query expression, we will use the
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/helper/OCLHelper.html" target="_new">
 						<code class="code">OCLHelper</code>
 					</a> object, which provides convenient operations for parsing queries and constraints
 					(intended for processing constraints embedded in models).
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">boolean&nbsp;valid;<br>
 OCLExpression&lt;EClassifier&gt;&nbsp;query&nbsp;=&nbsp;null;<br>

 <br>
 try&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;create&nbsp;an&nbsp;OCL&nbsp;instance&nbsp;for&nbsp;Ecore<br>
 &nbsp;&nbsp;&nbsp;&nbsp;OCL&lt;?,&nbsp;EClassifier,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;Constraint,&nbsp;EClass,&nbsp;EObject&gt;&nbsp;ocl;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;ocl&nbsp;=&nbsp;OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;create&nbsp;an&nbsp;OCL&nbsp;helper&nbsp;object<br>
 &nbsp;&nbsp;&nbsp;&nbsp;OCLHelper&lt;EClassifier,&nbsp;?,&nbsp;?,&nbsp;Constraint&gt;&nbsp;helper&nbsp;=&nbsp;ocl.createOCLHelper();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;set&nbsp;the&nbsp;OCL&nbsp;context&nbsp;classifier<br>
 &nbsp;&nbsp;&nbsp;&nbsp;helper.setContext(EXTLibraryPackage.Literals.WRITER);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;query&nbsp;=&nbsp;helper.createQuery("self.books-&gt;collect(b&nbsp;:&nbsp;Book&nbsp;|&nbsp;b.category)-&gt;asSet()");<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;record&nbsp;success<br>
 &nbsp;&nbsp;&nbsp;&nbsp;valid&nbsp;=&nbsp;true;<br>
 }&nbsp;catch&nbsp;(ParserException&nbsp;e)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;record&nbsp;failure&nbsp;to&nbsp;parse<br>
 &nbsp;&nbsp;&nbsp;&nbsp;valid&nbsp;=&nbsp;false;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;System.err.println(e.getLocalizedMessage());<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The example above parses an expression that computes the distinct categories
 					of
 					<code class="code">Book</code> s associated with a
 					<code class="code">Writer</code>.  The possible
 					reasons why it would fail to parse (in which case a

 					<code class="code">ParserException</code> is thrown) include:
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>syntactical problems:  misplaced or missing constructs such as closing</p>
 </li>
 </ul>
 </div>
 <p>		parentheses, variable declarations, type expressions, etc.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>semantic problems:  unknown attributes or operations of the context</p>
 </li>
 </ul>
 </div>
 <p>		type or referenced types, unknown packages, classes, etc.</p>
 </div>
 <div class="section" title="Parsing OCL Constraints">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ParsingOCLConstraints"></a>Parsing OCL Constraints</h3>
 </div>
 </div>
 </div>
 <p>OCL is primarily intended for the specification of
 					<span class="emphasis"><em>constraint</em></span> s.  Unlike
 					queries, there are a variety of different kinds of constraints used in different
 					places in a model.  These include classifier invariants, operation constraints,
 					and attribute derivation constraints.  The
 					<code class="code">OCLHelper</code>
 					can parse these for us.
 				</p>
 <p>Let&rsquo;s imagine the confusion that arises from a library that has more than
 					one book of the same title (we are not intending to model copies).  We will
 					create an invariant constraint for @Book@s stipulating
 					that this is not permitted:</p>
 <div class="literallayout">
 <p>
 <code class="code">Constraint&nbsp;invariant&nbsp;=&nbsp;null;<br>

 <br>
 try&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;set&nbsp;the&nbsp;OCL&nbsp;context&nbsp;classifier<br>
 &nbsp;&nbsp;&nbsp;&nbsp;helper.setContext(EXTLibraryPackage.Literals.LIBRARY);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;invariant&nbsp;=&nbsp;helper.createInvariant(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Library.allInstances()-&gt;forAll(b1,&nbsp;b2&nbsp;|&nbsp;b1&nbsp;&lt;&gt;&nbsp;b2&nbsp;implies&nbsp;b1.title&nbsp;&lt;&gt;&nbsp;b2.title)");<br>
 }&nbsp;catch&nbsp;(ParserException&nbsp;e)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;record&nbsp;failure&nbsp;to&nbsp;parse<br>
 &nbsp;&nbsp;&nbsp;&nbsp;System.err.println(e.getLocalizedMessage());<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>Parsing constraints differs from parsing query expressions because they have
 					additional well-formedness rules that the parser checks.  For example, an
 					invariant constraint must be boolean-valued, an attribute derivation constraint
 					must conform to the type of the attribute, and such constructs as @pre
 					and
 					<code class="code">oclIsNew()</code> may only be used in operation post-condition constraints.
 				</p>
 </div>
 <div class="section" title="Evaluating OCL Expressions and Constraints">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="EvaluatingOCLExpressionsandConstraints"></a>Evaluating OCL Expressions and Constraints</h3>
 </div>
 </div>
 </div>
 <p>More interesting than parsing an OCL expression or constraint is evaluating it
 					on some object.  The
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/Query.html" target="_new">
 						<code class="code">Query</code>
 					</a>
 					interface provides two methods for evaluating expressions. Queries are
 					constructed by factory methods on the
 					<code class="code">OCL</code> class.
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/Query.html#evaluate(org.eclipse.emf.ecore.EObject)" target="_new">
 								<code class="code">Object evaluate(Object)</code>
 							</a>

 </p>
 </li>
 </ul>
 </div>
 <p>		evaluates the expression on the specified object, returning the result.
 							The caller is expected to know the result type, which could be a
 							primitive,
 					<code class="code">EObject</code>, or a collection.  There
 							are variants of this method for evaluation of the query on multiple
 							objects and on no object at all (for queries that require no "self"
 							context).
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/Query.html#check(org.eclipse.emf.ecore.EObject)" target="_new">
 								<code class="code">boolean evaluate(Object)</code>
 							</a>

 </p>
 </li>
 </ul>
 </div>
 <p>		This method evaluates a special kind of OCL expression called a

 					<span class="emphasis"><em>constraint</em></span>.  Constraints are distinguished from other OCL queries
 							by having a boolean value; thus, they can be used to implement invariant
 							or pre/post-condition constraints.  There are variants for checking
 							multiple objects and for selecting/rejecting elements of a list that
 							satisfy the constraint.
 				</p>
 <p>In order to support the
 					<code class="code">allInstances()</code> operation on OCL types,
 					the
 					<code class="code">OCL</code> API provides the
 				</p>
 <p>

 <a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/OCL.html#setExtentMap(java.util.Map)" target="_new">
 						<code class="code">setExtentMap(Map&lt;CLS, ? extends Set&lt;? extends E&gt;&gt; extentMap)</code>
 					</a>
 					method.  This assigns a mapping of classes (in the Ecore binding,

 					<code class="code">EClass</code> es) to the sets of their instances.  By default,
 					the
 					<code class="code">OCL</code> provides a dynamic map that computes the
 					extents on demand from the contents of a
 					<code class="code">Resource</code>.
 					An alternative extent map can be
 					found in
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/opposites/ExtentMap.html" target="_new">
 						<code class="code">org.eclipse.ocl.ecore.opposites.ExtentMap</code>
 					</a> .
 					We will use a custom extent map in evaluating a query expression that finds
 					books that have the same title as a designated book:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">//&nbsp;create&nbsp;an&nbsp;extent&nbsp;map<br>
 Map&lt;EClass,&nbsp;Set&lt;?&nbsp;extends&nbsp;EObject&gt;&gt;&nbsp;extents&nbsp;=&nbsp;new&nbsp;HashMap&lt;EClass,&nbsp;Set&lt;?&nbsp;extends&nbsp;EObject&gt;&gt;();<br>
 Set&lt;Book&gt;&nbsp;books&nbsp;=&nbsp;new&nbsp;HashSet&lt;Book&gt;();<br>
 extents.put(EXTLibraryPackage.Literals.BOOK,&nbsp;books);<br>

 <br>
 //&nbsp;tell&nbsp;the&nbsp;OCL&nbsp;environment&nbsp;what&nbsp;our&nbsp;classifier&nbsp;extents&nbsp;are<br>
 ocl.setExtentMap(extents);<br>

 <br>
 Library&nbsp;library&nbsp;=&nbsp;EXTLibraryFactory.eINSTANCE.createLibrary();<br>

 <br>
 Book&nbsp;myBook&nbsp;=&nbsp;EXTLibraryFactory.eINSTANCE.createBook();<br>
 myBook.setTitle("David&nbsp;Copperfield");<br>
 books.add(myBook);<br>

 <br>
 //&nbsp;this&nbsp;book&nbsp;is&nbsp;in&nbsp;our&nbsp;library<br>
 library.add(myBook);<br>

 <br>
 Writer&nbsp;dickens&nbsp;=&nbsp;EXTLibraryFactory.eINSTANCE.createWriter();<br>
 dickens.setName("Charles&nbsp;Dickens");<br>

 <br>
 Book&nbsp;aBook&nbsp;=&nbsp;EXTLibraryFactory.eINSTANCE.createBook();<br>
 aBook.setTitle("The&nbsp;Pickwick&nbsp;Papers");<br>
 aBook.setCategory(BookCategory.MYSTERY_LITERAL);<br>
 books.add(aBook);<br>
 aBook&nbsp;=&nbsp;EXTLibraryFactory.eINSTANCE.createBook();<br>
 aBook.setTitle("David&nbsp;Copperfield");<br>
 aBook.setCategory(BookCategory.BIOGRAPHY_LITERAL);&nbsp;&nbsp;//&nbsp;not&nbsp;actually,&nbsp;of&nbsp;course!<br>
 books.add(aBook);<br>
 aBook&nbsp;=&nbsp;EXTLibraryFactory.eINSTANCE.createBook();<br>
 aBook.setTitle("Nicholas&nbsp;Nickleby");<br>
 aBook.setCategory(BookCategory.BIOGRAPHY_LITERAL);&nbsp;&nbsp;//&nbsp;not&nbsp;really<br>
 books.add(aBook);<br>

 <br>
 dickens.addAll(books);&nbsp;&nbsp;//&nbsp;Dickens&nbsp;wrote&nbsp;these&nbsp;books<br>
 library.addAll(books);&nbsp;&nbsp;//&nbsp;and&nbsp;they&nbsp;are&nbsp;all&nbsp;in&nbsp;our&nbsp;library<br>

 <br>
 //&nbsp;use&nbsp;the&nbsp;query&nbsp;expression&nbsp;parsed&nbsp;before&nbsp;to&nbsp;create&nbsp;a&nbsp;Query<br>
 Query&lt;EClassifier,&nbsp;EClass,&nbsp;EObject&gt;&nbsp;eval&nbsp;=&nbsp;ocl.createQuery(query);<br>

 <br>
 Collection&lt;?&gt;&nbsp;result&nbsp;=&nbsp;(Collection&lt;?&gt;)&nbsp;eval.evaluate(dickens);<br>
 System.out.println(result);<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The same
 					<code class="code">Query</code> API is used to check constraints.
 					Using the
 					<code class="code">library</code> and
 					<code class="code">extents</code> map from above and the
 					constraint parsed previously:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">eval&nbsp;=&nbsp;ocl.createQuery(constraint);<br>

 <br>
 boolean&nbsp;ok&nbsp;=&nbsp;eval.check(library);<br>

 <br>
 System.out.println(ok);<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 <div class="section" title="Implementing Content Assist">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ImplementingContentAssist"></a>Implementing Content Assist</h3>
 </div>
 </div>
 </div>
 <p>The
 					<code class="code">OCLHelper</code> interface provides an operation that
 					computes content-assist proposals in an abstract form, as

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/helper/Choice.html" target="_new">
 						<code class="code">Choice</code>
 					</a> s.
 					An application&rsquo;s UI can then convert these to JFace&rsquo;s

 					<code class="code">ICompletionProposal</code> type.
 				</p>
 <p>Obtaining completion choices consists of supplying a partial OCL expression
 					(up to the cursor location in the UI editor) to the

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/helper/OCLHelper.html#getSyntaxHelp(org.eclipse.ocl.helper.ConstraintKind" target="_new">
 						<code class="code">OCLHelper::getSyntaxHelp(ConstraintKind, String)</code>
 					</a>, java.lang.String)
 					method.  This method requires a
 					<code class="code">ConstraintKind</code>
 					enumeration indicating the type of constraint that is to be parsed (some OCL
 					constructs are restricted in the kinds of constraints in which they may be used).
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">helper.setContext(EXTLibraryPackage.Literals.BOOK);<br>

 <br>
 List&lt;Choice&gt;&nbsp;choices&nbsp;=&nbsp;helper.getSyntaxHelp(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;ConstraintKind.INVARIANT,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;"Book.allInstances()-&gt;excluding(self).");<br>

 <br>
 for&nbsp;(Choice&nbsp;next&nbsp;:&nbsp;choices)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;switch&nbsp;(next.getKind())&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;case&nbsp;OPERATION:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;case&nbsp;SIGNAL:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;the&nbsp;description&nbsp;is&nbsp;already&nbsp;complete<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(next.getDescription());<br>
 &nbsp;&nbsp;&nbsp;&nbsp;case&nbsp;PROPERTY:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;case&nbsp;ENUMERATION_LITERAL:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;case&nbsp;VARIABLE:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(next.getName()&nbsp;+&nbsp;"&nbsp;:&nbsp;"&nbsp;+&nbsp;next.getDescription();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;break;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;default:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(next.getName());<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;break;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>A sample of the output looks like:</p>
 <div class="literallayout">
 <p>
 <code class="code">author&nbsp;:&nbsp;Writer<br>
 title&nbsp;:&nbsp;String<br>
 oclIsKindOf(typespec&nbsp;:&nbsp;OclType)<br>
 oclAsType(typespec&nbsp;:&nbsp;OclType)&nbsp;:&nbsp;T<br>
 ...<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The choices also provide the model element that they represent, from which a
 					more sophisticated application can construct appropriate JFace completions,
 					including context information, documentation, etc.</p>
 </div>
 <div class="section" title="Working with the AST">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="WorkingwiththeAST"></a>Working with the AST</h3>
 </div>
 </div>
 </div>
 <p>The OCL Interpreter models the OCL language using EMF&rsquo;s Ecore with support for
 					Java-style generic types.  The bindings of this generic Abstract Syntax Model
 					for Ecore and for UML substitutes these metamodels' constructs for the generic
 					type parameters, plugging in the definitions of the &ldquo;classifier&rdquo;, &ldquo;operation&rdquo;,
 					&ldquo;constraint&rdquo;, etc. constructs of the OCL vocabulary.  These bindings, then,
 					support persistence in or as an adjunct to Ecore and UML models.</p>
 <p>For processing the abstract syntax tree (AST) parsed from OCL text, the API
 					supplies a

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/utilities/Visitor.html" target="_new">
 						<code class="code">Visitor</code>
 					</a>
 					interface.  By implementing this interface (or extending the

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/utilities/AbstractVisitor.html" target="_new">
 						<code class="code">AbstractVisitor</code>
 					</a>
 					class, which is recommended), we can walk the AST of an OCL expression to
 					transform it in some way.
 					This is exactly what the interpreter, itself, does to evaluate an
 					expression:  it just walks the expression using an evaluation visitor.  For
 					example, we can count the number times that a specific attribute is
 					referenced in an expression:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">helper.setContext(EXTLibraryPackage.Literals.BOOK);<br>

 <br>
 OCLExpression&lt;EClassifier&gt;&nbsp;query&nbsp;=&nbsp;helper.parseQuery(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;"Book.allInstances()-&gt;select(b&nbsp;:&nbsp;Book&nbsp;|&nbsp;b&nbsp;&lt;&gt;&nbsp;self&nbsp;and&nbsp;b.title&nbsp;=&nbsp;self.title)");<br>

 <br>
 AttributeCounter&nbsp;visitor&nbsp;=&nbsp;new&nbsp;AttributeCounter(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;EXTLibraryPackage.Literals.BOOK__TITLE);<br>

 <br>
 System.out.println(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;"Number&nbsp;of&nbsp;accesses&nbsp;to&nbsp;the&nbsp;'Book::title'&nbsp;attribute:&nbsp;"&nbsp;+&nbsp;query.accept(visitor));<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>where the visitor is defined thus:</p>
 <div class="literallayout">
 <p>
 <code class="code">class&nbsp;AttributeCounter&nbsp;extends&nbsp;AbstractVisitor&lt;Integer,<br>
 		EClassifier,&nbsp;EOperation,&nbsp;EStructuralFeature,&nbsp;EEnumLiteral,<br>
 		EParameter,&nbsp;EObject,&nbsp;EObject,&nbsp;EObject,&nbsp;Constraint&gt;&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;private&nbsp;final&nbsp;EAttribute&nbsp;attribute;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;AttributeCounter(EAttribute&nbsp;attribute)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super(0);&nbsp;&nbsp;//&nbsp;initialize&nbsp;the&nbsp;result&nbsp;of&nbsp;the&nbsp;AST&nbsp;visitiation&nbsp;to&nbsp;zero<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;this.attribute&nbsp;=&nbsp;attribute;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;protected&nbsp;Integer&nbsp;handlePropertyCallExp(PropertyCallExp&lt;EClassifier,&nbsp;EStructuralFeature&gt;&nbsp;callExp,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;		Integer&nbsp;sourceResult,&nbsp;List&lt;Integer&gt;&nbsp;sourceResults)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;(callExp.getReferredProperty()&nbsp;==&nbsp;attribute)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;count&nbsp;one<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;result++;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;result;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 <div class="section" title="Serialization">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Serialization"></a>Serialization</h3>
 </div>
 </div>
 </div>
 <p>Because the OCL expression AST is a graph of EMF objects, we can serialize it
 					to an XMI file and deserialize it again later.  To save our example expression,
 					we start over by initializing our
 					<code class="code">OCL</code> instance with
 					a resource in which it will persist the environment and in which we will
 					persist the parsed expression.  The key is in the persistence of the
 					environment:  OCL defines a variety of classes on the fly by template
 					instantiation.  These include collection types, tuple types, and message types.
 					Other elements needing to be persisted are additional operations and attributes
 					that may be defined in the local environment.
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">//&nbsp;create&nbsp;a&nbsp;resource&nbsp;in&nbsp;which&nbsp;to&nbsp;store&nbsp;our&nbsp;parsed&nbsp;OCL&nbsp;expressions&nbsp;and&nbsp;constraints<br>
 Resource&nbsp;res&nbsp;=&nbsp;resourceSet.createResource(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;URI.createPlatformResourceURI("/MyProject/myOcl.xmi",&nbsp;true);<br>

 <br>
 //&nbsp;initialize&nbsp;a&nbsp;new&nbsp;OCL&nbsp;environment,&nbsp;persisted&nbsp;in&nbsp;this&nbsp;resource<br>
 ocl&nbsp;=&nbsp;OCL.newInstance(EcoreEnvironmentFactory.INSTANCE,&nbsp;res);<br>

 <br>
 //&nbsp;for&nbsp;the&nbsp;new&nbsp;OCL&nbsp;environment,&nbsp;create&nbsp;a&nbsp;new&nbsp;helper<br>
 helper&nbsp;=&nbsp;OCL.createOCLHelper();<br>

 <br>
 helper.setContext(EXTLibraryPackage.Literals.BOOK);<br>

 <br>
 //&nbsp;try&nbsp;a&nbsp;very&nbsp;simple&nbsp;expression<br>
 OCLExpression&lt;EClassifier&gt;&nbsp;query&nbsp;=&nbsp;helper.createQuery("self.title");<br>

 <br>
 //&nbsp;store&nbsp;our&nbsp;query&nbsp;in&nbsp;this&nbsp;resource.&nbsp;&nbsp;All&nbsp;of&nbsp;its&nbsp;necessary&nbsp;environment&nbsp;has<br>
 //&nbsp;already&nbsp;been&nbsp;stored,&nbsp;so&nbsp;we&nbsp;insert&nbsp;the&nbsp;query&nbsp;as&nbsp;the&nbsp;first&nbsp;resource&nbsp;root<br>
 res.getContents().add(0,&nbsp;query);<br>

 <br>
 res.save(Collections.emptyMap());<br>
 res.unload();<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>To load a saved OCL expression is just as easy:</p>
 <div class="literallayout">
 <p>
 <code class="code">Resource&nbsp;res&nbsp;=&nbsp;resourceSet.getResource(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;URI.createPlatformResourceURI("/MyProject/myOcl.xmi",&nbsp;true),<br>
 &nbsp;&nbsp;&nbsp;&nbsp;true;<br>

 <br>
 @SuppressWarnings("unchecked")<br>
 OCLExpression&lt;EClassifier&gt;&nbsp;query&nbsp;=&nbsp;(OCLExpression&lt;EClassifier&gt;)&nbsp;res.getContents().get(0);<br>

 <br>
 System.out.println(ocl.evaluate(myBook,&nbsp;query));<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>In the snippet above, we used the
 					<code class="code">OCL</code>'s convenience
 					method for a one-shot evaluation of a query.  Looking at the contents of the
 					XMI document that we saved, we see that the
 					<code class="code">self</code>
 					variable declaration is not owned by the query expression, but is, rather,
 					free-standing.  The
 					<code class="code">ExpressionInOCL</code> metaclass solves
 					this problem by providing properties that contain context variable declarations,
 					including
 					<code class="code">self</code> and (in the context of operations)
 					operation parameters.
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">&lt;?xml&nbsp;version="1.0"&nbsp;encoding="ASCII"?&gt;<br>
 &lt;xmi:XMI&nbsp;xmi:version="2.0"&nbsp;xmlns:xmi="http://www.omg.org/XMI"&nbsp;xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&nbsp;xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"&nbsp;xmlns:ocl.ecore="http://www.eclipse.org/ocl/1.1.0/Ecore"&gt;<br>
 &nbsp;&nbsp;&lt;ocl.ecore:PropertyCallExp&nbsp;xmi:id="_897fVPfmEduCQ48h829a5g"&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&lt;eType&nbsp;xsi:type="ocl.ecore:PrimitiveType"&nbsp;href="http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore#/0/String"/&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&lt;source&nbsp;xsi:type="ocl.ecore:VariableExp"&nbsp;xmi:id="_897fVvfmEduCQ48h829a5g"&nbsp;name="self"&nbsp;referredVariable="_897fUvfmEduCQ48h829a5g"&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;eType&nbsp;xsi:type="ecore:EClass"&nbsp;href="http:///org/eclipse/emf/examples/library/extlibrary.ecore/1.0.0#//Book"/&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&lt;/source&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&lt;referredProperty&nbsp;xsi:type="ecore:EAttribute"&nbsp;href="http:///org/eclipse/emf/examples/library/extlibrary.ecore/1.0.0#//Book/title"/&gt;<br>
 &nbsp;&nbsp;&lt;/ocl.ecore:PropertyCallExp&gt;<br>
 &nbsp;&nbsp;&lt;ocl.ecore:Variable&nbsp;xmi:id="_897fUvfmEduCQ48h829a5g"&nbsp;name="self"&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&lt;eType&nbsp;xsi:type="ecore:EClass"&nbsp;href="http:///org/eclipse/emf/examples/library/extlibrary.ecore/1.0.0#//Book"/&gt;<br>
 &nbsp;&nbsp;&lt;/ocl.ecore:Variable&gt;<br>
 &lt;/xmi:XMI&gt;<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 <div class="section" title="Summary">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Summary3"></a>Summary</h3>
 </div>
 </div>
 </div>
 <p>To illustrate how to work with the OCL API, we</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Parsed and validated OCL expressions and constraints.</p>
 </li>
 <li class="listitem">
 <p>Evaluated OCL query expressions and constraints.</p>
 </li>
 <li class="listitem">
 <p>Obtained content-assist suggestions for the completion of OCL expressions.</p>
 </li>
 <li class="listitem">
 <p>Transformed an OCL expression AST using the
 							<span class="emphasis"><em>Visitor</em></span> pattern.
 						</p>
 </li>
 <li class="listitem">
 <p>Saved and loaded OCL expressions to/from XMI resources.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="section" title="Extensions (in the Unified/Pivot OCL prototype)">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Extensions"></a>Extensions (in the Unified/Pivot OCL prototype)</h2>
 </div>
 </div>
 </div>
 <p>This section highlights some of the OCL extensions prototyped by the Pivot OCL.</p>
 <div class="section" title="Models">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Models"></a>Models</h3>
 </div>
 </div>
 </div>
 <p>The Abstract Syntax classes and interfaces are autogenerated from Pivot.ecore using standard EMF tooling. Pivot.ecore is auto-generated by custom QVTo transformations from OMG&rsquo;s UML.xmi and prototype OCL.uml models. This gives some degree of UML alignment.</p>
 <p>The Standard Library is defined by OCL-2.5.oclstdlib for which an OCLstdlib Xtext editor is available. The library is therefore modelled.</p>
 <p>The Concrete Syntax classes and editors are also autogenerated from Ecore modesl using standard EMF tooling. Autogeneation of the Ecore models from UML modesl is still work in progress.</p>
 <p>The grammars are defined by Xtext models.</p>
 <p>The run-time Value classes and interfaces are partially generated from Values.ecore. Full auto-generation is still work in progress.</p>
 <p>There is also a model of the code generation intermediate.</p>
 </div>
 <div class="section" title="XMI">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="XMI"></a>XMI</h3>
 </div>
 </div>
 </div>
 <p>The abstract syntax models are fully persistable as standard XMI using the *.oclas file extension. Pivot.oclas and OCL-2.5.oclas models form part of the Eclipse OCL distribution.</p>
 <p>The problem of interchange of synthetic types such as Sequence(String) is solved by an orphan package in which a singleton copy of every singleton is maintained.</p>
 <p>The problem of Complete OCL&rsquo;s open classes allowing additional features is solved by CompleteModel/CompletePackage/CompleteClass additions to the abstract syntax so that a CompleteClass may aggregate many ordinary Classes; one from the primary user (UML/Ecore) model, any number of further (Compete OCL or OCLstdlib) over;ays.</p>
 <p>The problem of references to unnavigable opposites is solved by an OppositePropertyCallExp class.</p>
 <p>The problem of references to modelled Iterations is resolved by adding a referredIteration property to IterateExp/IteratorExp.</p>
 <p>The problem of references to Stereotype properties is resolved by normalizing the UML representation to exploit regular Class/Property usage.</p>
 <p>The problem of references to Association properties is resolved by normalizing the UML representation to exploit regular Class/Property usage.</p>
 </div>
 <div class="section" title="Templates">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Templates"></a>Templates</h3>
 </div>
 </div>
 </div>
 <p>In OMG OCL, types such as Sequence(String) magically associate String and an ill-defined concept of T. In UML and consequently the UML-aligned pivot OCL, String is a TemplateParameter for which further classes such as TemplateParameterSubstitution define bindings. The use of magic T for library classes is genertalized to arbitrary user
 					classes and operations; jusr like UML. Template types of cource conform and since in OCL all values are immutable a
 					Set(Integer) is conformat to a Sert(Real) and a Set(OclAny). This can bew slightly surprising since typos may not lead immediately to type errors, rather an expression with inferred OclAny errors. Use the hovertext to inspect your expression types.</p>
 </div>
 <div class="section" title="Extensibility">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Extensibility"></a>Extensibility</h3>
 </div>
 </div>
 </div>
 <p>The Pivot OCL is extended by the Eclipse QVTd project to support QVTc and QVTr. The models are therefore extensible, but not readily so. Rather too mauch Java programming is required. True extensibilitty and in partocular a modular OCL Standrad Library is still work in progress.</p>
 </div>
 <div class="section" title="Operation Overloading">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OperationOverloading"></a>Operation Overloading</h3>
 </div>
 </div>
 </div>
 <p>The buck passing between UML and OCL in regards to operation overloading is resolved in the Pivot OCL by implementing a Java-style dynamic dispatch to the most derived implmentation with a matching signature.</p>
 </div>
 <div class="section" title="Stereotypes">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Stereotypes"></a>Stereotypes</h3>
 </div>
 </div>
 </div>
 <p>The UML specification hinyts in regards to base_XXX and extension_XXX properties are followed through in conjunction with an ElementExtension lass to model  the instance of a Stereotype. Typesafe stereotype navigation is therefore possible without resorting to the proprietary getXXX Java API of Eclipse UML2.</p>
 </div>
 <div class="section" title="Safe Navigation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="SafeNavigation"></a>Safe Navigation</h3>
 </div>
 </div>
 </div>
 <p>The UML [ 1 ] and [ ?  ] multiplicities are exploited to distinguish nullable and non-null objects and diagnose unsafe navigations. To make this useful an extension to null-free collections is possible by defing e.g Set(String[*|1]) as
 					a Set of String with unbounded [ * ] collection multiplity and never-null [ 1 ] element multiplicity. The additional ?. and &ldquo;?-&gt;&rdquo; safe navigation operators avoid nullhazards. See
 					<a class="ulink" href="http://www.eclipse.org/modeling/mdt/ocl/docs/publications/OCL2015SafeNavigation/SafeNavigation.pdf" target="_new">Safe Navigation in OCL</a> for more details.
 				</p>
 </div>
 <div class="section" title="Reflection">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Reflection"></a>Reflection</h3>
 </div>
 </div>
 </div>
 <p>In the Pivot OCL the oclType() libary method has a pivot::Class return type allowing further navigation to make reflective access to the user metamodel.</p>
 </div>
 <div class="section" title="Lambda Expressions">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="LambdaExpressions"></a>Lambda Expressions</h3>
 </div>
 </div>
 </div>
 <p>OCL has always had hidden lambda expressions in order to define iteratpr bodies. The Pivot OCL reifies these so that the Standard Library uses a templated LambdaType as part of its modelling. Variables and Parameters may use LamabdaType and so ooffer full lambda expression capability.</p>
 </div>
 <div class="section" title="Map(K,V)">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="MapKV"></a>Map(K,V)</h3>
 </div>
 </div>
 </div>
 <p>The Map type provides a familiar functionality comprising a set of keys with associated values.</p>
 <p>Like all other OCL types, the Map type is immutable; there are therefore no
 					<span class="bold"><strong>put</strong></span> or
 					<span class="bold"><strong>set</strong></span> operations, rather a new Map may be created by
 					<span class="bold"><strong>including</strong></span> a key-value pair tigether with an old Map.
 				</p>
 <p>The content of a Map may be accessed using
 					<span class="bold"><strong>at</strong></span>, which returns invalid for an unknown key in the same way as an ordered collection returns invalid for an unknown index.
 				</p>
 <p>A Map may be created explicitly using the new Map Literal Syntax. Thus
 					<span class="bold"><strong>Map(Integer,String){1 &lt;- &lsquo;one&rsquo;,2 &lt;- &lsquo;two&rsquo;}</strong></span>
 					creates a Map of Integer to String with
 					<span class="bold"><strong>'one'</strong></span> bound to
 					<span class="bold"><strong>1</strong></span> and
 					<span class="bold"><strong>'two'</strong></span> bound to
 					<span class="bold"><strong>2</strong></span>. The type
 					<span class="bold"><strong>(Integer,String)</strong></span>
 					parameterisation can be omitted.
 					<span class="bold"><strong>null</strong></span> but not
 					<span class="bold"><strong>invalid</strong></span> values are permitted as keys and values.
 				</p>
 <p>The new
 					<span class="bold"><strong>collectBy</strong></span> iteration may be used to construct a map from a collection or map. The iterators of the
 					<span class="bold"><strong>collectBy</strong></span> define the keys and the value of the body of defines the values. For instance
 					<span class="bold"><strong>Sequence{1..10}-&gt;collectBy(i | i+i)}</strong></span> builds a map from the values 1 to 10 to the even values 2 to 20.
 				</p>
 <p>Most standard collection iteration operations are available for Maps using the map keys as the (primary) iterator. A secondary value iterator may be specified using the new binds-to syntax. Thus
 					<span class="bold"><strong>Map{1&lt;-1,2&lt;-4,3&lt;-9}-&gt;reject(k&lt;-v | k = 2 or v = 9}</strong></span> defines a reject iteration over the three entry map, with a primary iterator
 					<span class="bold"><strong>k</strong></span> over the set of keys and a secondary co-iterator
 					<span class="bold"><strong>v</strong></span> over the values bound to each key. The body causes the second entry with key 2, and the third entry with value 9 to be rejected leaving just a one entry map.
 				</p>
 <div class="section" title="Details">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="Details"></a>Details</h4>
 </div>
 </div>
 </div>
 <p>The OCL metamodel is extended by a MapLiteralExp and MapType. A new abstract IterableType captures the iterable commonality of CollectionType and MapType without making map a collection.</p>
 <p>The OCL standard library defines the new Map operations and the new Collection::collectBy itetation.</p>
 <p>The OCL syntax is extended by the MapLiteralExp syntax and the binds-to co-iterator syntax for all iterators.</p>
 <p>The OCL run-time is extended by a MapValue and an abstract IteravleValue to capture the commonality with CollectionValue.</p>
 </div>
 </div>
 </div>
 <div class="section" title="Installing the Eclipse OCL Examples and Editors">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Installation"></a>Installing the Eclipse OCL Examples and Editors</h2>
 </div>
 </div>
 </div>
 <p>These instructions have been updated for Eclipse Mars; Eclipse 4.5, EMF 2.11, OCL 6.0.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Some screenshots may be slightly out of date.</p>
 </li>
 </ul>
 </div>
 <p>The OCL User Interface (console, editors, debugger and validity view)
 				is not part of the core OCL functionality included in the
 				Eclipse Modeling Tools Package, so although you may have OCL installed and be able
 				to read this tutorial via the
 				<span class="bold"><strong>Help-&gt;Help Contents-&gt;OCL Documentation</strong></span>, you may
 				not have the OCL examples installed.
 			</p>
 <p>An easy way to test whether you have the OCL Examples installed is
 				to right click on a *.ecore file and see whether

 				<span class="bold"><strong>OCLinEcore Editor</strong></span> appears in the
 				<span class="bold"><strong>Open With</strong></span> submenu.
 			</p>
 <p>If OCL is not installed at all, or if just the examples are not installed,
 				the following installation step will automatically install the OCL Examples
 				and all required projects such as
 				<span class="bold"><strong>EMF</strong></span>,
 				<span class="bold"><strong>UML2</strong></span>,
 				<span class="bold"><strong>MWE2</strong></span>,
 				<span class="bold"><strong>Xpand</strong></span>
 				and
 				<span class="bold"><strong>Xtext</strong></span>.
 			</p>
 <p>Left-click on
 				<span class="bold"><strong>Help</strong></span> in the Eclipse menu-bar then left-click on
 				<span class="bold"><strong>Install New Software...</strong></span>
 				and select the
 				<span class="bold"><strong>Luna &ndash; http://download.eclipse.org/releases/luna</strong></span> update site
 				from the pull-down menu to
 				<span class="bold"><strong>Work with</strong></span> and be patient while the available updates
 				are identified. Then type
 				<span class="bold"><strong>OCL</strong></span> in the filter text, click on the expand item preceding
 				the
 				<span class="bold"><strong>Modeling</strong></span> category and then check
 				<span class="bold"><strong>OCL Examples and Editors SDK</strong></span>.
 			</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4900-install_software.png"></div>
 <p>

 </p>
 <p>Select
 				<span class="bold"><strong>Next</strong></span>.
 			</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4900-install_details.png"></div>
 <p>

 </p>
 <p>Select
 				<span class="bold"><strong>Next</strong></span> again and read the license agreement. Set to accept it.
 			</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/4900-install_license.png"></div>
 <p>

 </p>
 <p>Select
 				<span class="bold"><strong>Finish</strong></span> and be patient while the software is downloaded and installed.
 				Select
 				<span class="bold"><strong>Restart Now</strong></span> when prompted to do so.
 			</p>
 <div class="section" title="Troubleshooting">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Troubleshooting2"></a>Troubleshooting</h3>
 </div>
 </div>
 </div>
 <p>Eclipse Modeling Projects have a large number of classes and so require a
 					large amount of PermGen space on a Sun JVM. If you are using default Eclipse
 					startup settings you are liable to encounter OutOfMemoryExceptions. Therefore
 					follow the advice in
 					<a class="ulink" href="http://wiki.eclipse.org/IRC_FAQ#How_do_I_start_Eclipse.3F" target="_new">How do I start Eclipse</a>
 					and set XX:PermSize to at least 64M, either on your Eclipse command line, or your
 					Eclipse shortcut or in the
 					<span class="bold"><strong>eclipse.ini</strong></span> adjacent to
 					<span class="bold"><strong>eclipse.exe</strong></span>. If you are using a 64 bit machine
 					or plan to use graphical modeling tools such as Papyrus or Sirius, 128M is almost certainly necessary.
 				</p>
 </div>
 </div>
 </div>
 <div class="chapter" title="Chapter&nbsp;5.&nbsp;Examples">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title">
 <a name="Examples"></a>Chapter&nbsp;5.&nbsp;Examples</h2>
 </div>
 </div>
 </div>
 <div class="section" title="Royal and Loyal Example Project">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="RoyalAndLoyalExample"></a>Royal and Loyal Example Project</h2>
 </div>
 </div>
 </div>
 <p>The RoyalAndLoyal example project provides a substantial example of a Complete OCL document
 				complementing an independent Ecore meta-model.</p>
 <p>This is the standard example used in many OCL texts and courses. It was first produced as part of
 				the
 				<span class="emphasis"><em>The Object Constraint Language Second Edition</em></span> by
 				<span class="emphasis"><em>Jos Warmer</em></span> and
 				<span class="emphasis"><em>Anneke Kleppe</em></span>.
 			</p>
 <p>This example may be used to explore a wide variety of OCL syntaxes and their presentation in the Complete OCL editor.</p>
 <p>You may install the example by selecting
 				<span class="bold"><strong>Example...</strong></span> from the
 				<span class="bold"><strong>New</strong></span> menu, then selecting
 				<span class="bold"><strong>Royal and Loyal Example</strong></span> under the
 				<span class="bold"><strong>OCL (Object Constraint Language) plugins</strong></span>.
 			</p>
 <p>Open
 				<span class="bold"><strong>RoyalAndLoyal.ecore</strong></span> with the OCLinEcore editor to explore the Ecore metamodel. Note how the Outline can be alphabeticized and so provide a useful overview. The outline very similar to the conventional Sample Ecore Editor tree view.
 			</p>
 <p>Open
 				<span class="bold"><strong>RoyalAndLoyal.ocl</strong></span> with the CompleteOCL editor to explore the OCL. Note how the full AST can be explored in the Outline.
 			</p>
 </div>
 <div class="section" title="Empty Example Project">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="EmptyExample"></a>Empty Example Project</h2>
 </div>
 </div>
 </div>
 <p>The Empty example project creates an empty project with a Java class path set up to assist in the use of OCL.</p>
 <p>This assistance is not really necessary now that the editors are based on Xtext and now that an XMI representation is not automatically saved in a
 				<span class="bold"><strong>bin</strong></span> directory.
 			</p>
 <p>The OCL editors can be used wherever Ecore editors can be used. </p>
 <p>It is not necessary for a project to have a Java nature.</p>
 <p>It is not necessary for a project to have an Xtext nature. If you add an Xtext nature, your OCL files will be built automatically when other files in the project or its dependencies change. This can significantly clutter the Problems View if you have problems with your OCL, and may significantly increase build times.</p>
 </div>
 <div class="section" title="OCLinEcore Tutorial Example Project">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OCLinEcoreTutorialExampleProject"></a>OCLinEcore Tutorial Example Project</h2>
 </div>
 </div>
 </div>
 <p>The OCLinEcore Tutorial project provides the conclusion of the
 				<a class="ulink" href="OCLinEcoreTutorial" target="_new">OCLinEcore Tutorial</a> and the material for the
 				<a class="ulink" href="GettingStarted" target="_new">Getting Started</a> quick introduction.
 			</p>
 <p>The project provides an example of OCL embedded in Ecore that is also used by the
 				<a class="link" href="#CodeGenerationTutorial" title="Code Generation tutorial">Code Generation Tutorial</a> and
 				<a class="link" href="#DebuggerTutorial" title="Debugger tutorial">Debugger tutorial</a>.
 			</p>
 </div>
 <div class="section" title="Complete OCL Tutorial Example Project">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="CompleteOCLTutorialExampleProject"></a>Complete OCL Tutorial Example Project</h2>
 </div>
 </div>
 </div>
 <p>The Complete OCL Tutorial project provides examples for the the
 				<a class="ulink" href="CompleteOCLTutorial" target="_new">Complete OCL Tutorial</a>.
 			</p>
 <p>The project provides examples Complete OCL documents that complement Ecore, UML, Xtext and XMI.</p>
 </div>
 <div class="section" title="OCL Interpreter Example">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="OCLInterpreterExample"></a>OCL Interpreter Example</h2>
 </div>
 </div>
 </div>
 <div class="section" title="Introduction">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Introduction"></a>Introduction</h3>
 </div>
 </div>
 </div>
 <p>This example illustrates the usage of the generic OCL Parser API to parse and evaluate OCL query expressions and constraints within the SDK. It demonstrates how to author OCL expressions and evaluate them against elements of library model instances, or against Ecore and UML elements.  For Ecore and UML models, a further option of parsing (not evaluating) model-level (M1 in the OMG modeling stack) constraints is available.</p>
 </div>
 <div class="section" title="References">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="References4"></a>References</h3>
 </div>
 </div>
 </div>
 <p>Please refer to the document
 					<a class="ulink" href="ExamplesOverview" target="_new">Object Constraint Language Examples Overview</a> for reviewing the library meta-model used as the basis for demonstrating the capabilities in this example.
 				</p>
 </div>
 <div class="section" title="Description">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Description"></a>Description</h3>
 </div>
 </div>
 </div>
 <p>This example plug-in is named
 					<code class="code">org.eclipse.emf.ocl.examples.interpreter</code>. This plug-in contributes the
 					<code class="code">OCL Interpreter</code> menu to the library editor&rsquo;s main menu and context menu. The menu has one item:
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">Show Console</code>: Opens the interactive OCL console.
 						</p>
 </li>
 </ul>
 </div>
 <p>Please refer to the tutorial
 					<a class="link" href="#OCLInterpreterTutorial" title="Working with Classic OCL">OCL Interpreter Tutorial</a> for reviewing the code samples within this example.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/3200-lib_editor_contrib.png"></div>
 <p>

 </p>
 <p>The bottom field in the console accepts OCL expressions (comments supported). You can press
 					<span class="bold"><strong>Enter</strong></span> to evaluate on the currently selected element. You can press
 					<span class="bold"><strong>Ctrl+Enter</strong></span> or
 					<span class="bold"><strong>Shift+Enter</strong></span> to insert a newline. The top field shows the output and errors. The console can be cleared by the
 					<span class="bold"><strong>Eraser</strong></span> button and closed by the
 					<span class="bold"><strong>X</strong></span> button.
 				</p>
 <p>Because the
 					<code class="code">EXTLibrary</code> model is based on the Ecore metamodel, ensure that the
 					<code class="code">Ecore</code> metamodel is selected in the console&rsquo;s tool bar.  Also ensure that the
 					<code class="code">M2</code> modeling level is selected, as
 					<code class="code">EXTLibrary</code> is not a metamodel, so instances of it are not models.  Thus, the OCL expressions that
 					we create will target the Ecore meta-model, as the model of the EXTLibrary model.
 				</p>
 <p>Content-assist is automatically activated on typing any of "
 					<code class="code">.</code>", "
 					<code class="code">-&gt;</code>", "
 					<code class="code">::</code>", and "
 					<code class="code">^</code>".  Also,
 					<code class="code">Ctrl+Space</code> can be used to invoke content-assist at any time.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/3200-lib_console.png"></div>
 <p>

 </p>
 </div>
 <div class="section" title="Support for Ecore and UML Models">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="SupportforEcoreandUMLModels"></a>Support for Ecore and UML Models</h3>
 </div>
 </div>
 </div>
 <p>The OCL Console contributes an
 					<span class="bold"><strong>OCL-&gt;Show OCL Console</strong></span> menu action to the Ecore and UML editors (for
 					<code class="code">*.ecore</code> and
 					<code class="code">*.uml</code> models).  These actions automatically select the appropriate metamodel in the console.
 				</p>
 <p>For both Ecore and UML, parsing constraints at the
 					<code class="code">M1</code> (model) level is supported.  This implements a scratch pad for developing OCL constraints in the context of:
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>classifiers, for invariant constraints</p>
 </li>
 <li class="listitem">
 <p>operations, for pre/post condition constraints and body expressions</p>
 </li>
 <li class="listitem">
 <p>attributes, for initial-value and derivation constraints</p>
 </li>
 </ul>
 </div>
 <p>The console infers the kind of constraint from the selected element; in the case of an operation, it assumes a post-condition constraint as these constraints support a superset of the syntax for pre-conditions and body expressions.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/3200-ecore_console.png"></div>
 <p>

 </p>
 <p>The figure above shows the parsing of a derivation constraint on an Ecore property (an
 					<code class="code">EStructuralFeature</code>).
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/3200-uml_console.png"></div>
 <p>

 </p>
 <p>The figure above shows the parsing of an invariant constraint on a UML classifier (a
 					<code class="code">Class</code>).  Note that UML can model the
 					<code class="code">Job</code> as an association class; a roughly equivalent Ecore model is more verbose.
 				</p>
 </div>
 <div class="section" title="Example Code">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ExampleCode"></a>Example Code</h3>
 </div>
 </div>
 </div>
 <p>Refer to the code in this example if you need to:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>parse, validate and evaluate OCL queries and constraints on EMF model elements</p>
 </li>
 <li class="listitem">
 <p>implement content-assist for OCL constraints in your model editor</p>
 </li>
 </ul>
 </div>
 <p>

 <a class="ulink" href="http://www.eclipse.org/legal/epl-v20.html" target="_new">Copyright &copy; 2000, 2007 IBM Corporation and others. All Rights Reserved.</a>

 </p>
 </div>
 </div>
 </div>
 <div class="chapter" title="Chapter&nbsp;6.&nbsp;Classic Ecore/UML Programmers Guide">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title">
 <a name="ProgrammersGuide"></a>Chapter&nbsp;6.&nbsp;Classic Ecore/UML Programmers Guide</h2>
 </div>
 </div>
 </div>
 <p>The Ecore/UML Programmers Guide describes the ways in which the Ecore or UML bindings of Eclipse OCL can be used from Java programs.</p>
 <p>The Ecore binding has been available since Eclipse OCL 1.0.0 (Callisto). The UML binding was added in 1.1.0 (Europa). Both will remain for as long as necessary. Examples quality prototypes of the new UML-aligned Pivot binding were first available in 3.1.0 (Indigo). The Pivot binding
 			became the preferred binding in 6.0.0 (Mars). The Pivot binding is described in a separate
 			<a class="link" href="#PivotProgrammersGuide" title="Chapter&nbsp;7.&nbsp;Unified or Pivot Programmers Guide">Pivot Programmers Guide</a>.
 		</p>
 <p>The OCL Parser/Interpreter provides an implementation of the
 			<a class="ulink" href="http://www.omg.org/spec/OCL" target="_new">Object Constraint Language 2.4</a> specification for EMF-based metamodels and models.  It offers OCL
 			constraint and query parsing and evaluation, model-based validation, and
 			provides an infrastructure for content assist in textual editors.
 		</p>
 <p>The following features are supported in the current version:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Classifier invariant constraints</p>
 </li>
 <li class="listitem">
 <p>Operation precondition and postcondition constraints and body conditions</p>
 </li>
 <li class="listitem">
 <p>Property constraints (initial-value and derivation)</p>
 </li>
 <li class="listitem">
 <p>Attribute and operation definitions (def: expressions)</p>
 </li>
 <li class="listitem">
 <p>Package context declaration</p>
 </li>
 <li class="listitem">
 <p>Basic values and types</p>
 </li>
 <li class="listitem">
 <p>Collection types</p>
 </li>
 <li class="listitem">
 <p>Navigation of attributes and association ends</p>
 </li>
 <li class="listitem">
 <p>Operation invocation</p>
 </li>
 <li class="listitem">
 <p>Iteration expressions (all standard iterators)</p>
 </li>
 <li class="listitem">
 <p>Let expressions</p>
 </li>
 <li class="listitem">
 <p>If expressions</p>
 </li>
 <li class="listitem">
 <p>Tuples</p>
 </li>
 <li class="listitem">
 <p>Message expressions, including unspecified values</p>
 </li>
 <li class="listitem">
 <p>Operations predefined by OCL:  allInstances(), oclIsKindOf(), oclIsTypeOf(), oclAsType(), oclIsNew()</p>
 </li>
 <li class="listitem">
 <p>Escape syntax for illegal names:  type, operation, attribute, etc. names that correspond to OCL reserved words can be escaped in the standard fashion using a leading underscore (&lsquo;_&rsquo;).  In addition, names that contain spaces or tabs can be escaped by enclosing them in double-quotes (&lsquo;"&rsquo;; this is non-standard).  e.g.,
 					<code class="code">self.ownedRule-&gt;forAll(c : Constraint | c._context = self)</code>

 </p>
 </li>
 </ul>
 </div>
 <p>The above constructs are supported by the parser for parsing and
 			for evaluation, with the exception of the oclIsNew() operation and
 			message expressions.  All of the above are supported for both Ecore
 			and UML models.  The following are supported by default for UML
 			(both in parsing and evaluation):</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Navigation of non-navigable association ends (including those that are owned by the association)</p>
 </li>
 <li class="listitem">
 <p>Qualified association end navigation</p>
 </li>
 <li class="listitem">
 <p>Navigation to association classes, including source qualifiers</p>
 </li>
 <li class="listitem">
 <p>Operations predefined by OCL: oclIsInState()</p>
 </li>
 </ul>
 </div>
 <p>The following features are provided in addition to the OCL specification:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>String case conversion operations:  toUpper(), toLower()</p>
 </li>
 <li class="listitem">
 <p>Support for comparison (&lt;, &lt;=, etc.) and sorting of any java
 					<code class="code">Comparable</code> s of conformant types
 				</p>
 </li>
 <li class="listitem">
 <p>Transitive closure of associations:  closure(expr : OCLExpression) iterator</p>
 </li>
 <li class="listitem">
 <p>Navigation of &ldquo;hidden&rdquo; opposites of references specified in Ecore models using a
 					<code class="code">Property.oppositeRoleName</code> annotation with source
 					<code class="code">http://schema.omg.org/spec/MOF/2.0/emof.xml</code> on the forward reference, producing an
 					<code class="code">OppositePropertyCallExp</code> expression
 				</p>
 </li>
 </ul>
 </div>
 <p>The OCL implementation is defined in plug-ins for convenient deployment in
 			Eclipse, but as is the case for EMF, it can also be used stand-alone.  The
 			plug-ins are partitioned thus:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">org.eclipse.ocl</code>:  the core parsing, evaluation, and content assist services.  Definition of the OCL Abstract Syntax Model and Environment API.  These APIs are generic, independent of any particular metamodel (though using Ecore/EMF as the meta-meta-model).
 				</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">org.eclipse.ocl.ecore</code>:  implementation of the Ecore metamodel environment, binding the generic Environment and AST APIs to the Ecore language.  Provides support for working with OCL constraints and queries targeting Ecore models.
 				</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">org.eclipse.ocl.uml</code>:  implementation of the UML metamodel environment, binding the generic Environment and AST APIs to the UML language.  Provides support for working with OCL targeting UML models.
 				</p>
 </li>
 </ul>
 </div>
 <p>Please refer to the
 			<a class="link" href="#OCLInterpreterTutorial" title="Working with Classic OCL">OCL Interpreter Tutorial</a> for review of the code samples.
 		</p>
 <div class="section" title="Parsing Constraints and Queries">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="ParsingConstraints"></a>Parsing Constraints and Queries</h2>
 </div>
 </div>
 </div>
 <p>The OCL parser provides two APIs for parsing constraint and query expressions. The
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/helper/OCLHelper.html" target="_new">
 					<code class="code">OCLHelper</code>
 				</a> interface is designed primarily for parsing constraints and query expressions
 				embedded in models, such as Ecore or UML models.  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 serves as the main entrypoint into the parsing API but also implements the
 				parsing of
 				<a class="link" href="#ParsingDocuments" title="Parsing OCL Documents">OCL documents</a>, for example from
 				text files.  In both cases, the concept of
 				<code class="code">Environment</code>
 				is crucial.
 			</p>
 <div class="section" title="The OCL Environment">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheOCLEnvironment"></a>The OCL Environment</h3>
 </div>
 </div>
 </div>
 <p>The following diagram shows the core of the
 					<code class="code">Environment</code>
 					API, that clients of the OCL parser interact with:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5110-environment.png"></div>
 <p>

 </p>
 <p>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 is a generic type; its type parameters represent the various metaclasses
 					of the metamodels that OCL works with in the UML/MOF family of OMG specifications.
 					For example,
 					<code class="code">&lt;C&gt;</code> represents the Classifier
 					concept,
 					<code class="code">&lt;O&gt;</code> the Operation concept, etc.  See
 					the discussion of
 					<a class="link" href="#TargetMetamodels" title="OCL Relationship to Metamodels">metamodels supported by OCL</a>
 					for details of the mappings.  The same type parameter names are used consistently
 					throughout the OCL APIs to represent the same metaclasses.
 				</p>
 <p>The
 					<code class="code">OCL</code> class defines instances of autonomous OCL
 					parsing and evaluation environments.  It has a single root

 					<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> created by an

 					<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>
 					implementation for a particular EMF-based metamodel.  The OCL environment
 					consists, conceptually, of the model that is to be constrained together with
 					all of the constraints and additional operations and attributes defined (via
 					OCL) for the purpose of formulating constraints.
 				</p>
 <p>

 <code class="code">Environment</code> s nest.  Usually the root environment has
 					no correlation to an element in the model, or it may correspond to some

 					<code class="code">Package</code> providing a default namespace (called a package
 					context).  Alternatively, it may contain one or more nested environments
 					defining package namespaces.  A package context contains one or more classifier
 					contexts, which in turn can contain operation and/or attribute contexts.  Whereas
 					the purpose of a package context is primarily to assist in the look-up of named
 					model elements, the classifier, operation, and attribute contexts have deeper
 					meaning.
 				</p>
 <p>A classifier context defines the type of the
 					<code class="code">self</code>
 					variable in OCL constraints and queries.  By itself, it is the context for
 					invariant constraints for the context classifier.  Additionally, as the parent
 					context for operation and attribute constraints, it indicates the classifier
 					in which context an operation or attribute constraint applies; this may be the
 					classifier that defines these features, or it may inherit them from some more
 					general classifier.
 				</p>
 <p>An
 					<code class="code">Environment</code> may contain named

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/expressions/Variable.html" target="_new">
 						<code class="code">Variable</code>
 					</a> s
 					to which OCL expressions can refer.  The most common of these is

 					<code class="code">self</code>.  Others include the parameters defined by an
 					operation (and its
 					<code class="code">result</code>), in the case of an
 					operation context.  The OCL API even allows clients to add variables, in code,
 					to define &ldquo;global&rdquo; names.
 				</p>
 </div>
 <div class="section" title="Creating an OCL Environment">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CreatinganOCLEnvironment"></a>Creating an OCL Environment</h3>
 </div>
 </div>
 </div>
 <p>The static factory methods on the
 					<code class="code">OCL</code> class are used
 					to create instances.  It is a good practice to re-use the same OCL instance for
 					all parsing and evaluation of constraints and queries on a model while that
 					model is loaded (usually in some
 					<code class="code">ResourceSet</code> in an
 					editor).  Using the shared environment factory for the Ecore

 					<a class="link" href="#TargetMetamodels" title="OCL Relationship to Metamodels">metamodel</a>, we can create an OCL
 					environment suitable for parsing OCL constraints on any Ecore model and
 					evaluating them on instances of the model:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5110-creating.png"></div>
 <p>


 <a class="ulink" href="../references/5110-creating.txt" target="_new">[Text for cut and paste]</a>

 </p>
 <p>Several of the type parameters in the
 					<code class="code">OCL</code> generic type
 					signature are useful mostly within the OCL API.  We leave them, here, as wildcards.
 				</p>
 </div>
 <div class="section" title="The OCL Helper">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheOCLHelper"></a>The OCL Helper</h3>
 </div>
 </div>
 </div>
 <p>From an OCL instance, we can create a helper object with which to parse constraints
 					and additional operation/attribute definitions.  This

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/helper/OCLHelper.html" target="_new">
 						<code class="code">OCLHelper</code>
 					</a>
 					stores all of the instantiations of OCL template metaclasses (such as

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/types/CollectionType.html" target="_new">
 						<code class="code">CollectionType(T)</code>
 					</a>
 					and
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/types/TupleType.html" target="_new">
 						<code class="code">TupleType</code>
 					</a>
 					and additional operation/attribute definitions in the root environment of the

 					<code class="code">OCL</code> that created it.  This ensures that all of these
 					constructs are available for reuse in subsequent parsing.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5110-oclhelper.png"></div>
 <p>

 </p>
 <p>The
 					<code class="code">OCLHelper</code> is primarily designed for parsing
 					constraints and query expressions embedded in models, providing the following
 					API for that purpose:
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">createQuery()</code>: parses a query expression
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">createConstraint()</code>: parses a constraint of a given
 							<code class="code">ConstraintKind</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">createInvariant()</code>: convenience for invariant constraints
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">createPrecondition()</code>: convenience for pre-condition constraints
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">createPostcondition()</code>: convenience for post-condition constraints
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">createBodyCondition()</code>: convenience for body conditions
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">createInitialValueExpression()</code>: convenience for attribute initial values
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">createDerivedValueExpression()</code>: convenience for attribute derived values
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">defineOperation()</code>: convenience for additional operation definitions
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">defineAttribute()</code>: convenience for additional attribute definitions
 						</p>
 </li>
 </ul>
 </div>
 <p>Different kinds of constraints require different context environments.  The

 					<code class="code">setContext()</code>,
 					<code class="code">setOperationContext()</code>,
 					and
 					<code class="code">setAttributeContext()</code> methods create the appropriate
 					nested
 					<code class="code">Environment@s in the host @OCL</code>
 					instance&rsquo;s root environment.
 				</p>
 <p>The result of parsing a query expression is an

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/expressions/OCLExpression.html" target="_new">
 						<code class="code">OCLExpression</code>
 					</a>,
 					an instance of the
 					<a class="link" href="#AbstractSyntax" title="OCL Abstract Syntax Model">Abstract Syntax Model</a> .  The
 					result of parsing a constraint is an instance of the

 					<code class="code">Constraint</code> metaclass defined by the

 					<code class="code">OCL</code>'s
 					<a class="link" href="#TargetMetamodels" title="OCL Relationship to Metamodels">target metamodel</a> .
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5110-context.png"></div>
 <p>


 <a class="ulink" href="../references/5110-context.txt" target="_new">[Text for cut and paste]</a>

 </p>
 <p>Ecore does not define a
 					<code class="code">Constraint</code> metaclass, so the
 					OCL
 					<a class="link" href="#TargetMetamodels" title="OCL Relationship to Metamodels">binding</a> for Ecore supplies one.
 				</p>
 </div>
 <div class="section" title="Operation and Attribute Contexts">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OperationandAttributeContexts"></a>Operation and Attribute Contexts</h3>
 </div>
 </div>
 </div>
 <p>In the case of constraints on operations or attributes, the context consists
 					of two elements:  the constrained operation/attribute and a classifier in the
 					context of which the constraint is to apply.  This accounts for the possibility
 					that a classifier defines constraints on inherited features.  As an example,
 					consider the
 					<code class="code">EModelElement::getEAnnotation(EString)</code>
 					operation and
 					<code class="code">EReference::eReferenceType</code> property in the Ecore
 					metamodel.  These can be constrained as follows:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5110-define.png"></div>
 <p>


 <a class="ulink" href="../references/5110-define.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 </div>
 <div class="section" title="Evaluating Constraints and Queries">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="EvaluatingConstraints"></a>Evaluating Constraints and Queries</h2>
 </div>
 </div>
 </div>
 <p>In
 				<a class="link" href="#ParsingConstraints" title="Parsing Constraints and Queries">Parsing Constraints</a>, we saw how to use
 				the
 				<code class="code">OCLHelper</code> API for parsing OCL constraints and
 				query expressions.  Parsing constraints is very interesting in itself, but
 				we can also make OCL come alive in our applications by evaluating these
 				constraints.  For this, OCL provides a
 				<code class="code">Query</code> API.
 			</p>
 <div class="section" title="The OCL Query">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheOCLQuery"></a>The OCL Query</h3>
 </div>
 </div>
 </div>
 <p>Like the
 					<code class="code">OCLHelper</code> for parsing constraints, the OCL
 					facade object provides

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/Query.html" target="_new">
 						<code class="code">Query</code>
 					</a>
 					objects for evaluating constraints and query expressions.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5115-query.png"></div>
 <p>

 </p>
 <p>The
 					<code class="code">Query</code> encapsulates an

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/EvaluationEnvironment.html" target="_new">
 						<code class="code">EvaluationEnvironment</code>
 					</a>
 					providing the run-time values of context variables to the OCL interpreter.  These
 					context variables are set and retrieved using the following methods:
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">add(String, Object)</code>: adds a name-value binding for a variable
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">replace(String, Object)</code>:  replaces an existing variable binding
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">remove()</code>:  removes a variable binding
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">getValueOf(String)</code>: obtains a variable value
 						</p>
 </li>
 </ul>
 </div>
 <p>The context variables of primary interest are
 					<code class="code">self</code>
 					and, in operation constraints, the variables corresponding to its parameters.
 					The
 					<code class="code">EvaluationEnvironment</code> API is also used to supply
 					values for &ldquo;global&rdquo; variables added to the parsing
 					<code class="code">Environment</code>
 					by the client.
 				</p>
 <p>Another important consideration in the evaluation environment is the

 					<code class="code">allInstances()</code> operation, which obtains the entire
 					extent of a classifier.  For data types, this is a simple problem:  the extent
 					of an
 					<code class="code">Enumeration</code> is well defined and the extents of
 					other kinds of
 					<code class="code">DataType</code> s are undefined.  For

 					<code class="code">Class</code> extents, the
 					<code class="code">EvaluationEnvironment</code>
 					provides support for an extent map, mapping classes to the sets of their
 					instances, as determined by the client.  A client sets the extent map using the

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/OCL.html#setExtentMap(java.util.Map)" target="_new">
 						<code class="code">OCL.setExtentMap()</code>
 					</a>
 					method.  The default extent map, if none is provided by the client, lazily
 					computes the extent of a class from the EMF
 					<code class="code">Resource</code>
 					containing the context element of the evaluation. An alternative extent map can be
 					found in
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/opposites/ExtentMap.html" target="_new">
 						<code class="code">org.eclipse.ocl.ecore.opposites.ExtentMap</code>
 					</a>.
 				</p>
 <p>So, after optionally setting values of context variables (other than

 					<code class="code">self</code>; the
 					<code class="code">Query</code> takes care
 					of this) and an extent map, simply construct a query and use it to evaluate
 					the expression or check the constraint:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5115-check-all.png"></div>
 <p>


 <a class="ulink" href="../references/5115-check-all.txt" target="_new">[Text for cut and paste]</a>

 </p>
 <p>One of the advantages of the
 					<code class="code">Query</code> API is that a
 					query&rsquo;s evaluation environment can be reused for multiple evaluations, as
 					above.  The extent of any classifier is only computed once.  For convenience,
 					however, in situations where only a single evaluation is required, the

 					<code class="code">OCL</code> class provides shortcuts:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5115-check-one.png"></div>
 <p>


 <a class="ulink" href="../references/5115-check-one.txt" target="_new">[Text for cut and paste]</a>

 </p>
 <p>The
 					<code class="code">Query</code> API also provides methods that work on
 					multiple elements.  The first example, above, could be written more succinctly as:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5115-check-quick.png"></div>
 <p>


 <a class="ulink" href="../references/5115-check-quick.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 </div>
 <div class="section" title="Parsing OCL Documents">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="ParsingDocuments"></a>Parsing OCL Documents</h2>
 </div>
 </div>
 </div>
 <p>As we saw in the
 				<a class="link" href="#ParsingConstraints" title="Parsing Constraints and Queries">Parsing Constraints and Queries</a> topic, the OCL parser provides an
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/helper/OCLHelper.html" target="_new">
 					<code class="code">OCLHelper</code>
 				</a> API for parsing constraints embedded in models.  OCL also permits constraints
 				to be specified in a text document, as an adjunct to the model.  In this case,
 				the concrete syntax for context declarations indicates the context of
 				constraints, equivalent to their placement in models.
 			</p>
 <p>As an example, consider the following Complete OCL document: "</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5120-extlibrary.png"></div>
 <p>


 <a class="ulink" href="../references/5120-extlibrary.ocl" target="_new">[Text for cut and paste]</a>

 </p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 					The
 					<span class="emphasis"><em>import</em></span> on the first line is an extension supported by the Complete OCL editor for use with the Pivot meta-model. The
 					<span class="emphasis"><em>import</em></span> is ignored by the parsers for the Ecore or UML bindings, which assume that the relevant metamodels have been registered in either the global EPackage.Registry or the local EPackage.Registry passed to the EnvironmentFactory..
 				</p>
 </blockquote>
 </div>
 <p></p>
 <div class="section" title="The OCL Input">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheOCLInput"></a>The OCL Input</h3>
 </div>
 </div>
 </div>
 <p>The
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/OCLInput.html" target="_new">
 						<code class="code">OCLInput</code>
 					</a> class encapsulates an OCL document.  An input can be created from a string or an
 					input stream.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5120-input.png"></div>
 <p>

 </p>
 <p>Given an
 					<code class="code">OCLInput</code>, simply ask an
 					<code class="code">OCL</code> to parse it: "
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5120-parsing.png"></div>
 <p>


 <a class="ulink" href="../references/5120-parsing.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 <div class="section" title="Accessing the Constraints">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="AccessingtheConstraints"></a>Accessing the Constraints</h3>
 </div>
 </div>
 </div>
 <p>The
 					<code class="code">OCL</code> returns the list of constraints if they were
 					successfully parsed.  They are retained by the OCL (available via the

 					<code class="code">getConstraints()</code> method at any time), and in particular,
 					any definitions of additional operations or attributes are available for
 					subsequent constraint parsing.  Any number of OCL documents may be parsed by
 					the same
 					<code class="code">OCL</code> instance, combined also with constraints
 					parsed by
 					<code class="code">OCLHelpers</code>.  All of these constraints are
 					retained by the
 					<code class="code">OCL</code> environment.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5120-accessing.png"></div>
 <p>


 <a class="ulink" href="../references/5120-accessing.txt" target="_new">[Text for cut and paste]</a>

 </p>
 <p>The source for these examples may be found in the org.eclipse.ocl.ecore.tests plugin in model/parsingDocumentsExample.ocl and in src/org/eclipse/ocl/ecore/tests/DocumentationExamples.java.</p>
 </div>
 </div>
 <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" 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" title="Chapter&nbsp;7.&nbsp;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>
 <div class="section" title="Content Assist Support">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="ContentAssistSupport"></a>Content Assist Support</h2>
 </div>
 </div>
 </div>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 					The Content Assist facilities described here are used by the Interactive OCL Console. They are not used by the new Xtext-based Editors or the Interactive Xtext OCL Console.</p>
 </blockquote>
 </div>
 <p>
 				The
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/helper/OCLHelper.html" target="_new">
 					<code class="code">OCLHelper</code>
 				</a> API provides support for content-assist in rich editors, by parsing partial OCL
 				expressions and supplying completion suggestions. The

 				<code class="code">List&lt;Choice&gt; getSyntaxHelp(ConstraintKind, String)</code> operation
 				returns a list of suggestions for the next token to follow the end of the
 				expression fragment.
 			</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5140-contentassist.png"></div>
 <p>

 </p>
 <p>The
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/helper/Choice.html" target="_new">
 					<code class="code">Choice</code>
 				</a> objects returned by the helper include some convenient text strings (name and
 				description) to formulate basic JFace content-assist proposals.  Each choice
 				also carries a reference to the element that it represents, the kind of element
 				indicated by the
 				<code class="code">ChoiceKind</code> enumeration, for a more
 				sophisticated content assist that might inlude context information, documentation,
 				etc. as in Eclipse JDT.  The list of choices depends in part on the kind of
 				constraint expression that is to be completed, as for example, the

 				<code class="code">oclIsNew()</code> operation is only permitted in operation
 				post-conditions.
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">helper.setContext(EXTLibraryPackage.Literals.BOOK);<br>

 <br>
 List&lt;Choice&gt;&nbsp;choices&nbsp;=&nbsp;helper.getSyntaxHelp(ConstraintKind.INVARIANT,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;"Book.allInstances()-&gt;collect(author)-&gt;");<br>

 <br>
 for&nbsp;(Choice&nbsp;next&nbsp;:&nbsp;choices)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;switch&nbsp;(next.getKind())&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;case&nbsp;OPERATION:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;case&nbsp;SIGNAL:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;the&nbsp;description&nbsp;is&nbsp;already&nbsp;complete<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(next.getDescription());<br>
 &nbsp;&nbsp;&nbsp;&nbsp;case&nbsp;PROPERTY:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;case&nbsp;ENUMERATION_LITERAL:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;case&nbsp;VARIABLE:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(next.getName()&nbsp;+&nbsp;"&nbsp;:&nbsp;"&nbsp;+&nbsp;next.getDescription();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;break;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;default:<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(next.getName());<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;break;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 <div class="section" title="Syntax Completion Choices">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="SyntaxCompletionChoices"></a>Syntax Completion Choices</h3>
 </div>
 </div>
 </div>
 <p>The computation of
 					<code class="code">Choice</code> s is supported for the
 					following tokens, which may be used by a client as auto-assist triggers:
 				</p>
 <table id="N14DF1">
 <tr>

 <th>Token</th>
 						<th>Completion choices</th>

 </tr>
 <tr>

 <td>
 							<code class="code">.</code>
 						</td>
 						<td>Features applicable to the type of the expression to the left of the dot, or its element type if it is a collection. association classes (in the UML environment only)</td>

 </tr>
 <tr>

 <td>
 							<code class="code">-&gt;</code>
 						</td>
 						<td>Collection operations and iterators</td>

 </tr>
 <tr>

 <td>
 							<code class="code">::</code>
 						</td>
 						<td>Packages, types, enumeration literals, and states (in the UML environment only)</td>

 </tr>
 <tr>

 <td>
 							<code class="code">^</code>
 						</td>
 						<td>Operations and signals (in the UML environment only)</td>

 </tr>
 <tr>

 <td>
 							<code class="code">^^</code>
 						</td>
 						<td></td>

 </tr>
 <tr>

 <td></td>
 						<td>In other situations, the choices the current context variables and implicit references to features of the
 							<code class="code">self</code> variable.  For example, if the input is something like
 							<code class="code">""</code> or
 							<code class="code">"self.isOrdered and "</code>
 						</td>

 </tr>
 </table>
 <p>

 <span class="bold"><strong>Content-assist triggers</strong></span>

 </p>
 <p>The completion of partially specified identifiers is also supported, by
 					backtracking to look for one of these triggering tokens.  This supports
 					interactively narrowing the choices while the content-assist window is active.</p>
 <div class="literallayout">
 <p>
 <code class="code">choices&nbsp;=&nbsp;helper.getSyntaxHelp(ConstraintKind.POSTCONDITION,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;"self.author.oclIs");<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 </div>
 <div class="section" title="OCL Abstract Syntax Model">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="AbstractSyntax"></a>OCL Abstract Syntax Model</h2>
 </div>
 </div>
 </div>
 <p>The OCL Abstract Syntax Model is defined by the

 				<a class="ulink" href="http://www.omg.org/spec/OCL" target="_new">OCL Language 2.4 specification</a> .
 				We will not attempt to describe this model, here.  However, the Eclipse
 				implementation of OCL defines some extensions to this model that provide
 				additional services.  The most important of these is support for the

 				<span class="emphasis"><em>Visitor</em></span> design pattern.
 			</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5150-ast.png"></div>
 <p>

 </p>
 <div class="section" title="The Visitable and Visitor Interfaces">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheVisitableandVisitorInterfaces"></a>The Visitable and Visitor Interfaces</h3>
 </div>
 </div>
 </div>
 <p>All of the metaclasses in the Abstract Syntax Model (nodes in the AST) that can be visited implement the
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/utilities/Visitable.html" target="_new">
 						<code class="code">Visitable</code>
 					</a> interface.  It define a single operation
 					<code class="code">accept(Visitor)</code>. This method delegates to the appropriate
 					<code class="code">visitXyz(Xyz)</code> method of the
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/utilities/Visitor.html" target="_new">
 						<code class="code">Visitor</code>
 					</a> . The direct implementors of the
 					<code class="code">Visitable</code> interface are the
 					<code class="code">OCLExpression</code> and those metaclasses of the
 					<code class="code">Expressions</code> package that do not conform to
 					<code class="code">OCLExpression</code>:
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">Variable</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">CollectionLiteralPart</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">TupleLiteralPart</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">ExpressionInOCL</code>

 </p>
 </li>
 </ul>
 </div>
 <p>This last is not defined in the
 					<code class="code">Expressions</code> package
 					because it pertains to the placement of OCL in
 					<code class="code">Constraint</code>
 					elements in models.
 				</p>
 <p>The OCL parser, internally, defines a few implementations of visitors, including
 					a
 					<code class="code">ValidationVisitor</code> for validating OCL expressions and an

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/EvaluationVisitor.html" target="_new">
 						<code class="code">EvaluationVisitor</code>
 					</a> for evaluating OCL expressions.
 				</p>
 </div>
 <div class="section" title="Implementing a Visitor">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ImplementingaVisitor"></a>Implementing a Visitor</h3>
 </div>
 </div>
 </div>
 <p>The best way to implement a visitor is to extend the

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/utilities/AbstractVisitor.html" target="_new">
 						<code class="code">AbstractVisitor</code>
 					</a> class.  It provides a
 					<code class="code">result</code> variable of the generic
 					type parameter type
 					<code class="code">T</code> to store the result computed
 					by the visitor (optional) and a convenient pattern of selective method overrides
 					to process only those nodes of interest for the task at hand.
 				</p>
 <p>The
 					<code class="code">AbstractVisitor</code> provides implementations of all
 					of the
 					<code class="code">visitXyz()</code> interface methods that simply
 					return the current
 					<code class="code">result</code> value.  Furthermore, for
 					any internal nodes of the syntax tree (such as

 					<code class="code">OperationCallExp</code> and
 					<code class="code">IfExp</code>),
 					the
 					<code class="code">visitXyz()</code> methods recursively visit the child
 					nodes, feeding the results of those descents into a
 					<code class="code">handleXyz()</code>
 					method that the subclass can override to compute some result from the child
 					results.
 				</p>
 <p>Thus, a subclass needs only to selectively override the default implementations
 					of
 					<code class="code">visitXyz()</code> methods for leaf tree nodes and

 					<code class="code">handleXyz()</code> methods for non-leaves.  For example, to
 					find all variables that are declared but never used:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">OCLExpression&lt;Classifier&gt;&nbsp;expr&nbsp;=&nbsp;getExpression();&nbsp;&nbsp;//&nbsp;hypothetical&nbsp;source&nbsp;of&nbsp;an&nbsp;expression<br>

 <br>
 Set&lt;Variable&lt;Classifier,&nbsp;Parameter&gt;&gt;&nbsp;variables&nbsp;=&nbsp;expr.accept(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;new&nbsp;AbstractVisitor&lt;Set&lt;Variable&lt;Classifier,&nbsp;Parameter&gt;&gt;,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Classifier,&nbsp;Operation,&nbsp;Property,&nbsp;EnumerationLiteral,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Parameter,&nbsp;State,&nbsp;CallOperationAction,&nbsp;SendSignalAction,&nbsp;Constraint&gt;(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;new&nbsp;HashSet&lt;Variable&lt;Classifier,&nbsp;Parameter&gt;&gt;())&nbsp;{&nbsp;&nbsp;//&nbsp;initialize&nbsp;the&nbsp;result<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;@Override<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;protected&nbsp;Set&lt;Variable&lt;Classifier,&nbsp;Parameter&gt;&gt;&nbsp;handleVariable(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Variable&lt;Classifier,&nbsp;Parameter&gt;&nbsp;variable,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Set&lt;Variable&lt;Classifier,&nbsp;Parameter&gt;&gt;&nbsp;initResult)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;result.add(variable);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;result;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;@Override<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;Set&lt;Variable&lt;Classifier,&nbsp;Parameter&gt;&gt;&nbsp;visitVariableExp(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;VariableExp&lt;Classifier,&nbsp;Parameter&gt;&nbsp;v)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;result.remove(v.getReferredVariable());<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;result;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}});<br>

 <br>
 Set&lt;String&gt;&nbsp;varNames&nbsp;=&nbsp;new&nbsp;HashSet&lt;String&gt;();<br>
 for&nbsp;(Variable&lt;?,&nbsp;?&gt;&nbsp;next&nbsp;:&nbsp;variables)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;varNames.add(next.getName());<br>
 }<br>

 <br>
 System.out.println("Unused&nbsp;variables:&nbsp;+&nbsp;"&nbsp;varNames);<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 <div class="section" title="The OppositePropertyCallExp Extension">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="HiddenOpposites"></a>The OppositePropertyCallExp Extension</h3>
 </div>
 </div>
 </div>
 <p>In Ecore models, a reference may have defined an
 					<code class="code">opposite</code> reference, usually owned by the class that is
 					the type of the forward reference. An opposite reference has several, often undesirable or even
 					prohibitive, implications on the class owning it:
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>A getter and, for settable features with upper multiplicity 1, a setter will be added, requiring the class to know the class owning the forward reference. This would create cyclic component references if the two classes lived in different components and would therefore not be possible.</p>
 </li>
 <li class="listitem">
 <p>The default serialization format and usually the storage format for non-default model stores changes to include the opposite reference.</p>
 </li>
 </ul>
 </div>
 <p>Yet, particularly for expressing constraints over the instance models it is often instrumental
 					to be able to navigate such forward references also in reverse. The
 					<code class="code">OppositePropertyCallExp</code>
 					class which inherits from
 					<code class="code">NavigationCallExp</code> and is sibling of

 					<code class="code">PropertyCallExp</code> allows for this reverse navigation in OCL. It
 					points to the forward reference, and its semantics are to navigate this reference in reverse.
 				</p>
 <p>To allow for convenient creation of such expressions in the OCL concrete syntax, the standard
 					property call syntax, such as
 					<code class="code">self.x</code> can be used, where
 					<code class="code">x</code>
 					is not the name of a forward reference on
 					<code class="code">self</code>'s class but rather
 					an annotated name on a reference using
 					<code class="code">self</code>'s class or any of its
 					base classes as its type. To enable this feature, use the special environment factory class

 					<code class="code">EcoreEnvironmentFactoryWithHiddenOpposites</code> when initializing the
 					OCL environment, e.g., by passing such an object to the
 					<code class="code">OCL.newInstance(...)</code>
 					method.
 				</p>
 <p>The name for the reverse navigation can be specified by an

 					<a class="ulink" href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.6.0/org/eclipse/emf/ecore/EAnnotation.html" target="_new">
 						<code class="code">EAnnotation</code>
 					</a> with
 					source
 					<code class="code">http://schema.omg.org/spec/MOF/2.0/emof.xml</code> and with
 					details key
 					<code class="code">Property.oppositeRoleName</code>. The details value
 					contains the name by which the &ldquo;hidden&rdquo; opposite can be referred to in OCL
 					expressions.
 				</p>
 <p>If OCL delegates are to be used, the standard EPackage annotations with
 					<code class="code">invocationDelegate</code>,
 					<code class="code">settingDelegate</code> and
 					<code class="code">validationDelegate</code> details for the
 					<code class="code">http://www.eclipse.org/emf/2002/Ecore</code> source must be augmented as shown by a further
 					<code class="code">hiddenOpposites</code> detail for the
 					<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL</code> source.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5155-hidden-opposites.png"></div>
 <p>

 </p>
 <p>This additional annotation causes the
 					<code class="code">EnvironmentFactory</code>
 					functionality for the EPackage to be provided by an instance of the

 					<code class="code">EcoreEnvironmentFactoryWithHiddenOpposites</code> class
 					which uses the
 					<code class="code">DefaultOppositeEndFinder</code> class will be used for finding
 					and navigating the hidden opposites. More substantial customisation is possible by specifying
 					an
 					<code class="code">environmentFactoryClass</code> detail with the fully qualified
 					name of a derived
 					<code class="code">EcoreEnvironmentFactory</code> that
 					provides a constructor taking an
 					<code class="code">EPackage.Registry</code> argument.
 					Note, that the class specified must be visible by your Ecore model&rsquo;s bundle.
 				</p>
 </div>
 </div>
 <div class="section" title="Customizing the Environment">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="CustomizingtheEnvironment"></a>Customizing the Environment</h2>
 </div>
 </div>
 </div>
 <p>An application that integrates OCL may find it advantageous to provide its users with an
 				enhanced OCL environment, to simplify their task of formulating OCL constraints and queries.
 				For example, an application might define additional &ldquo;primitive&rdquo; operations on the OCL
 				standard data types that are pertinent to its domain, or &ldquo;global&rdquo; variables that inject
 				useful objects into the user&rsquo;s context. It is also possible to customize the way
 				&ldquo;hidden&rdquo; opposites are looked up and navigated, specifically to allow reverse navigation
 				across Ecore references that have no opposite defined.</p>
 <div class="section" title="Defining Global Variables">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="DefiningGlobalVariables"></a>Defining Global Variables</h3>
 </div>
 </div>
 </div>
 <p>Consider an application that allows end-users to specify conditions, using OCL, to filter
 					the objects that are shown in the user interface.  Given a sufficiently rich model
 					(expressed in Ecore or UML) of the objects that the UI presents, many conditions can be
 					expressed entirely in terms of this model.  However, some queries might depend on state
 					of the application, itself, not the data:  which perspective is active, whether some view
 					is showing, or even the time of day.  These are not characteristics of the objects that the
 					user wishes to filter.</p>
 <p>Such an application might, then, choose to define application-specific variables that a
 					filter condition can query:
 					<code class="code">app$perspective</code>,
 					<code class="code">app$views</code>,
 					<code class="code">app$time</code>.  Or, perhaps a
 					single variable
 					<code class="code">app$</code>, that has properties that a condition can access:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">--&nbsp;filter&nbsp;out&nbsp;OCL&nbsp;files&nbsp;in&nbsp;the&nbsp;Web&nbsp;Development&nbsp;perspective<br>
 self.extension&nbsp;=&nbsp;'ocl'&nbsp;and&nbsp;app$.perspective&nbsp;=&nbsp;'Web&nbsp;Development'<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>To do this, we define a small Ecore model of our application context, e.g.:</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5160-appcontext.png"></div>
 <p>

 </p>
 <p>Then, in the code that parses a user&rsquo;s filter condition:</p>
 <div class="literallayout">
 <p>
 <code class="code">OCL&lt;?,&nbsp;EClassifier,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;Constraint,&nbsp;EClass,&nbsp;EObject&gt;&nbsp;ocl;<br>
 ocl&nbsp;=&nbsp;OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);<br>

 <br>
 OCLHelper&lt;EClassifier,&nbsp;?,&nbsp;?,&nbsp;Constraint&gt;&nbsp;helper&nbsp;=&nbsp;ocl.createOCLHelper();<br>
 helper.setContext(MyPackage.Literals.FILE);<br>

 <br>
 //&nbsp;create&nbsp;a&nbsp;variable&nbsp;declaring&nbsp;our&nbsp;global&nbsp;application&nbsp;context&nbsp;object<br>
 Variable&lt;EClassifier,&nbsp;EParameter&gt;&nbsp;appContextVar&nbsp;=<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ExpressionsFactory.eINSTANCE.createVariable();<br>
 appContextVar.setName("app$");<br>
 appContextVar.setType(AppPackage.Literals.APP_CONTEXT);<br>

 <br>
 //&nbsp;add&nbsp;it&nbsp;to&nbsp;the&nbsp;global&nbsp;OCL&nbsp;environment<br>
 ocl.getEnvironment().addElement(appContextVar.getName(),&nbsp;appContextVar,&nbsp;true);<br>

 <br>
 List&lt;Constraint&gt;&nbsp;conditions&nbsp;=&nbsp;new&nbsp;ArrayList&lt;Constraint&gt;();<br>

 <br>
 //&nbsp;parse&nbsp;the&nbsp;user's&nbsp;filter&nbsp;conditions<br>
 for&nbsp;(String&nbsp;cond&nbsp;:&nbsp;getFilterConditions())&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;conditions.add(helper.createInvariant(cond));<br>
 }<br>

 <br>
 //&nbsp;apply&nbsp;the&nbsp;filters<br>
 applyFilters(conditions);<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The body of our hypothetical
 					<code class="code">applyFilters()</code> method must bind this
 					context variable to a value.  In this case, the value can be computed when we apply the
 					filters:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">AppContext&nbsp;appContext&nbsp;=&nbsp;AppFactory.eINSTANCE.createAppContext();<br>

 <br>
 //&nbsp;hypothetical&nbsp;workbench&nbsp;utilities<br>
 appContext.setPerspective(WorkbenchUtil.getCurrentPerspective());<br>
 appContext.getViews().addAll(WorkbenchUtil.getOpenViewIDs());<br>
 appContext.setTime(new&nbsp;Date());<br>

 <br>
 List&lt;Query&lt;EClassifier,&nbsp;EClass,&nbsp;EObject&gt;&gt;&nbsp;queries&nbsp;=<br>
 &nbsp;&nbsp;&nbsp;&nbsp;new&nbsp;ArrayListlt;Query&lt;EClassifier,&nbsp;EClass,&nbsp;EObject&gt;&gt;(constraints.size());<br>

 <br>
 for&nbsp;(Constraint&nbsp;next&nbsp;:&nbsp;constraints)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;Query&lt;EClassifier,&nbsp;EClass,&nbsp;EObject&gt;&nbsp;query&nbsp;=&nbsp;ocl.createQuery(next);<br>

 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;bind&nbsp;the&nbsp;variable&nbsp;value<br>
 &nbsp;&nbsp;&nbsp;&nbsp;query.getEvaluationEnvironment().add("app$",&nbsp;appContext());<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;queries.add(query);<br>
 }<br>

 <br>
 filter(queries);&nbsp;&nbsp;//&nbsp;applies&nbsp;these&nbsp;filters&nbsp;to&nbsp;the&nbsp;current&nbsp;objects<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;by&nbsp;evaluating&nbsp;the&nbsp;OCLS&nbsp;on&nbsp;them.<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 <div class="section" title="Defining Helper Operations in Java">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="DefiningHelperOperationsinJava"></a>Defining Helper Operations in Java</h3>
 </div>
 </div>
 </div>
 <p>OCL allows the definition of additional operations and attributes using
 					<code class="code">def:</code> expressions.  This is very convenient for the formulation of constraints, but what if the operation that we need is something like a regex pattern match?
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">class&nbsp;Person<br>
 inv&nbsp;valid_ssn:&nbsp;self.ssn.regexMatch('\d{3}-\d{3}-\d{3}')&nbsp;&lt;&gt;&nbsp;null<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>We might try to define this using OCL, as an additional operation on the OCL Standard
 					Library&rsquo;s
 					<code class="code">String</code> primitive type:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">class&nbsp;String<br>
 def:&nbsp;regexMatch(pattern&nbsp;:&nbsp;String)&nbsp;:&nbsp;String&nbsp;=<br>
 &nbsp;&nbsp;&nbsp;&nbsp;--&nbsp;???<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The operations available in the OCL Standard Library simply are not sufficient to express
 					the value of this operation, which should return the substring matching a regex pattern or

 					<code class="code">null</code> if the pattern does not match.  We need to implement this
 					operation in Java.  We can do that by creating a custom
 					<code class="code">Environment</code>
 					that knows how to look up this operation, and an
 					<code class="code">EvaluationEnvironment</code>
 					that knows how it is implemented.
 				</p>
 <p>First, let&rsquo;s start by defining a specialization of the

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/EcoreEnvironment.html" target="_new">
 						<code class="code">EcoreEnvironment</code>
 					</a> . The constructor that is used to initialize the root environment of an
 					<code class="code">OCL</code>
 					instance will add our
 					<code class="code">regexMatch</code> additional operation to the

 					<code class="code">String</code> primitive type.  The constructor that is used to create
 					nested environments copies the operation from its parent.
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">class&nbsp;MyEnvironment&nbsp;extends&nbsp;EcoreEnvironment&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;EOperation&nbsp;regexMatch;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;this&nbsp;constructor&nbsp;is&nbsp;used&nbsp;to&nbsp;initialize&nbsp;the&nbsp;root&nbsp;environment<br>
 &nbsp;&nbsp;&nbsp;&nbsp;MyEnvironment(EPackage.Registry&nbsp;registry)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super(registry);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;defineCustomOperations();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;this&nbsp;constructor&nbsp;is&nbsp;used&nbsp;to&nbsp;initialize&nbsp;child&nbsp;environments<br>
 &nbsp;&nbsp;&nbsp;&nbsp;MyEnvironment(MyEnvironment&nbsp;parent)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super(parent);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;get&nbsp;the&nbsp;parent's&nbsp;custom&nbsp;operations<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;regexMatch&nbsp;=&nbsp;parent.regexMatch;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>

 <br>
 	//&nbsp;override&nbsp;this&nbsp;to&nbsp;provide&nbsp;visibility&nbsp;of&nbsp;the&nbsp;inherited&nbsp;protected&nbsp;method<br>
 &nbsp;&nbsp;&nbsp;&nbsp;@Override<br>
 &nbsp;&nbsp;&nbsp;&nbsp;protected&nbsp;void&nbsp;setFactory(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EnvironmentFactory&lt;EPackage,&nbsp;EClassifier,&nbsp;EOperation,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EStructuralFeature,&nbsp;EEnumLiteral,&nbsp;EParameter,&nbsp;EObject,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CallOperationAction,&nbsp;SendSignalAction,&nbsp;Constraint,&nbsp;EClass,&nbsp;EObject&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;factory)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super.setFactory(factory);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;use&nbsp;the&nbsp;AbstractEnvironment's&nbsp;mechanism&nbsp;for&nbsp;defining<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;"additional&nbsp;operations"&nbsp;to&nbsp;add&nbsp;our&nbsp;custom&nbsp;operation&nbsp;to<br>
 &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;OCL's&nbsp;String&nbsp;primitive&nbsp;type<br>
 &nbsp;&nbsp;&nbsp;&nbsp;private&nbsp;void&nbsp;defineCustomOperations()&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;pattern-matching&nbsp;operation<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;regexMatch&nbsp;=&nbsp;EcoreFactory.eINSTANCE.createEOperation();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;regexMatch.setName("regexMatch");<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;regexMatch.setEType(getOCLStandardLibrary().getString());<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EParameter&nbsp;parm&nbsp;=&nbsp;EcoreFactory.eINSTANCE.createEParameter();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;parm.setName("pattern");<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;parm.setEType(getOCLStandardLibrary().getString());<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;regexMatch.getEParameters().add(parm);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;annotate&nbsp;it&nbsp;so&nbsp;that&nbsp;we&nbsp;will&nbsp;recognize&nbsp;it<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;in&nbsp;the&nbsp;evaluation&nbsp;environment<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EAnnotation&nbsp;annotation&nbsp;=&nbsp;EcoreFactory.eINSTANCE.createEAnnotation();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;annotation.setSource("MyEnvironment");<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;regexMatch.getEAnnotations().add(annotation);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;define&nbsp;it&nbsp;as&nbsp;an&nbsp;additional&nbsp;operation&nbsp;on&nbsp;OCL&nbsp;String<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;addOperation(getOCLStandardLibrary().getString(),&nbsp;regexMatch);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>Next, we will define the corresponding specialization of the

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/EcoreEvaluationEnvironment.html" target="_new">
 						<code class="code">EcoreEvaluationEnvironment</code>
 					</a> that will know how to evaluate calls to this custom operation:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">class&nbsp;MyEvaluationEnvironment&nbsp;extends&nbsp;EcoreEvaluationEnvironment&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;MyEvaluationEnvironment()&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>

 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;MyEvaluationEnvironment(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EvaluationEnvironment&lt;EClassifier,&nbsp;EOperation,&nbsp;EStructuralFeature,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EClass,&nbsp;EObject&gt;&nbsp;parent)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super(parent);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;Object&nbsp;callOperation(EOperation&nbsp;operation,&nbsp;int&nbsp;opcode,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Object&nbsp;source,&nbsp;Object[]&nbsp;args)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;(operation.getEAnnotation("MyEnvironment")&nbsp;==&nbsp;null)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;not&nbsp;our&nbsp;custom&nbsp;regex&nbsp;operation<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;super.callOperation(operation,&nbsp;opcode,&nbsp;source,&nbsp;args);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;("regexMatch".equals(operation.getName()))&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Pattern&nbsp;pattern&nbsp;=&nbsp;Pattern.compile((String)&nbsp;args[0]);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Matcher&nbsp;matcher&nbsp;=&nbsp;pattern.matcher((String)&nbsp;source);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;matcher.matches()?&nbsp;matcher.group()&nbsp;:&nbsp;null;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;throw&nbsp;new&nbsp;UnsupportedOperationException();&nbsp;&nbsp;//&nbsp;unknown&nbsp;operation<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>Finally, we define a specialization of 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> that creates our custom environments:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">class&nbsp;MyEnvironmentFactory&nbsp;extends&nbsp;EcoreEnvironmentFactory&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;Environment&lt;EPackage,&nbsp;EClassifier,&nbsp;EOperation,&nbsp;EStructuralFeature,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EEnumLiteral,&nbsp;EParameter,&nbsp;EObject,&nbsp;CallOperationAction,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SendSignalAction,&nbsp;Constraint,&nbsp;EClass,&nbsp;EObject&gt;&nbsp;createEnvironment()&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MyEnvironment&nbsp;result&nbsp;=&nbsp;new&nbsp;MyEnvironment(getEPackageRegistry());<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;result.setFactory(this);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;result;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;Environment&lt;EPackage,&nbsp;EClassifier,&nbsp;EOperation,&nbsp;EStructuralFeature,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EEnumLiteral,&nbsp;EParameter,&nbsp;EObject,&nbsp;CallOperationAction,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SendSignalAction,&nbsp;Constraint,&nbsp;EClass,&nbsp;EObject&gt;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;createEnvironment(Environment&lt;EPackage,&nbsp;EClassifier,&nbsp;EOperation,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EStructuralFeature,&nbsp;EEnumLiteral,&nbsp;EParameter,&nbsp;EObject,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CallOperationAction,&nbsp;SendSignalAction,&nbsp;Constraint,&nbsp;EClass,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EObject&gt;&nbsp;parent)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;(!(parent&nbsp;instanceof&nbsp;MyEnvironment))&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;throw&nbsp;new&nbsp;IllegalArgumentException(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Parent&nbsp;environment&nbsp;must&nbsp;be&nbsp;my&nbsp;environment:&nbsp;"&nbsp;+&nbsp;parent);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MyEnvironment&nbsp;result&nbsp;=&nbsp;new&nbsp;MyEnvironment((MyEnvironment)&nbsp;parent);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;result.setFactory(this);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;result;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>

 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;EvaluationEnvironment&lt;EClassifier,&nbsp;EOperation,&nbsp;EStructuralFeature,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EClass,&nbsp;EObject&gt;&nbsp;createEvaluationEnvironment()&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;new&nbsp;MyEvaluationEnvironment();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>

 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;EvaluationEnvironment&lt;EClassifier,&nbsp;EOperation,&nbsp;EStructuralFeature,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EClass,&nbsp;EObject&gt;&nbsp;createEvaluationEnvironment(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EvaluationEnvironment&lt;EClassifier,&nbsp;EOperation,&nbsp;EStructuralFeature,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EClass,&nbsp;EObject&gt;&nbsp;parent)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;new&nbsp;MyEvaluationEnvironment(parent);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>Now, we can use our environment to parse the kind of expression that we were looking for:</p>
 <div class="literallayout">
 <p>
 <code class="code">OCL&lt;?,&nbsp;EClassifier,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;Constraint,&nbsp;EClass,&nbsp;EObject&gt;&nbsp;ocl;<br>
 ocl&nbsp;=&nbsp;OCL.newInstance(new&nbsp;MyEnvironmentFactory());<br>

 <br>
 OCLHelper&lt;EClassifier,&nbsp;?,&nbsp;?,&nbsp;Constraint&gt;&nbsp;helper&nbsp;=&nbsp;ocl.createOCLHelper();<br>
 helper.setContext(MyPackage.Literals.PERSON);<br>

 <br>
 //&nbsp;double&nbsp;the&nbsp;'\'&nbsp;to&nbsp;escape&nbsp;it&nbsp;in&nbsp;a&nbsp;Java&nbsp;string&nbsp;literal<br>
 Constraint&nbsp;validSSN&nbsp;=&nbsp;helper.createInvariant(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"self.ssn.regexMatch('\\d{3}-\\d{3}-\\d{3}')&nbsp;&lt;&gt;&nbsp;null");<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 Person&nbsp;person&nbsp;=&nbsp;getPersonToValidate();<br>

 <br>
 System.out.printf("%s&nbsp;valid&nbsp;SSN:&nbsp;%b%n",&nbsp;person,&nbsp;ocl.check(person,&nbsp;validSSN));<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 <div class="section" title="Selecting a Package Lookup Strategy">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="SelectingaPackageLookupStrategy"></a>Selecting a Package Lookup Strategy</h3>
 </div>
 </div>
 </div>
 <p>When package names are provided in OCL expressions, e.g., when representing types in an

 					<code class="code">oclIsKindOf</code> call, these names are looked up using a specific
 					strategy. By default, the lookup proceeds starting at the parsing context, traversing
 					up the package hierarchy. If the package name cannot be resolved this way, for the Ecore
 					binding a lookup is performed in the
 					<code class="code">EPackage.Registry</code>. By
 					default, the package name provided is compared to the names of the packages that are
 					contained as values in the registry.
 				</p>
 <p>In rare cases there may be ambiguous package names. For example, if an OCL expression
 					is to be parsed using a classifier from the OCL AST metamodel as its context, the
 					context package is
 					<code class="code">ocl::ecore</code>. If such an expression is
 					trying to reference a type from the EMF Ecore package with package name

 					<code class="code">ecore</code>, the EMF Ecore package is hidden by the lookup
 					happening relative to the context package. Instead of the EMF Ecore package, the

 					<code class="code">ocl::ecore</code> package will be found.
 				</p>
 <p>Such an ambiguity can be resolved by using a dedicated
 					<code class="code">EPackage.Registry</code>
 					which registers the otherwise ambiguous packages with a special &ldquo;URI&rdquo; that represents a
 					simple alias name for the package. In order to force the OCL parser to look up packages
 					by those alias names, an option needs to be set on the OCL environment, as follows:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">&nbsp;&nbsp;&nbsp;&nbsp;Registry&nbsp;r&nbsp;=&nbsp;new&nbsp;EPackageRegistryImpl();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;r.putAll(EPackage.Registry.INSTANCE);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;r.put("EMFEcore",&nbsp;EcorePackage.eINSTANCE);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;r.put("OCLEcore",&nbsp;org.eclipse.ocl.ecore.EcorePackage.eINSTANCE);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;OCL&nbsp;ocl&nbsp;=&nbsp;OCL.newInstance(new&nbsp;EcoreEnvironmentFactory(r));<br>
 &nbsp;&nbsp;&nbsp;&nbsp;((EcoreEnvironment)&nbsp;ocl.getEnvironment()).setOption(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ParsingOptions.PACKAGE_LOOKUP_STRATEGY,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ParsingOptions.PACKAGE_LOOKUP_STRATEGIES.<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;LOOKUP_PACKAGE_BY_ALIAS_THEN_NAME);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;Helper&nbsp;helper&nbsp;=&nbsp;ocl.createOCLHelper();<br>
 &nbsp;&nbsp;&nbsp;&nbsp;helper.setContext(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.ecore.EcorePackage.eINSTANCE.getOCLExpression());<br>
 &nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.ecore.OCLExpression&nbsp;expr&nbsp;=&nbsp;helper.createQuery(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"self.oclIsKindOf(EMFEcore::EClassifier)&nbsp;and&nbsp;not<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;self.oclIsKindOf(OCLEcore::OCLExpression)");<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>In the example above, two packages with ambiguous simple names (EMF Ecore package and
 					OCL Ecore package, both with simple name
 					<code class="code">ecore</code>) are added with
 					alias names
 					<code class="code">EMFEcore</code> and
 					<code class="code">OCLEcore</code>,
 					respectively. The package lookup strategy is then set to

 					<code class="code">LOOKUP_PACKAGE_BY_ALIAS_THEN_NAME</code> which allows OCL expressions to reference
 					the packages by their aliases, as in

 					<code class="code">self.oclIsKindOf(EMFEcore::EClassifier) and not self.oclIsKindOf(OCLEcore::OCLExpression)</code>.
 				</p>
 <p>Note, that the use of a delegating registry (constructor

 					<code class="code">EPackageRegistryImpl(EPackage.Registry)</code>) does not work
 					because a registry initialized this way does not forward the call to

 					<code class="code">values()</code> which would be required by the OCL
 					package lookup implementation. Instead, if the packages registered with the
 					default registry are required, they need to be copied to a new registry
 					using
 					<code class="code">putAll</code> as shown above.
 				</p>
 </div>
 <div class="section" title="Customizing Hidden Opposite Lookup and Navigation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CustomizingHiddenOppositeLookupandNavigation"></a>Customizing Hidden Opposite Lookup and Navigation</h3>
 </div>
 </div>
 </div>
 <p>The default
 					<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> produces environments which can find references that have an annotation with source
 					<code class="code">http://schema.omg.org/spec/MOF/2.0/emof.xml</code>
 					that have a detail with key
 					<code class="code">Property.oppositeRoleName</code>. In the class that is the type of the reference,
 					and all its subclasses, for OCL this annotation defines an otherwise &ldquo;hidden&rdquo; opposite property which can be used
 					in OCL expressions. This can be convenient when it is not possible or desirable to define an explicit
 					opposite reference, e.g., because the class that would have to own the opposite reference can&rsquo;t easily be
 					modified or the serialization of that class must not be changed.
 				</p>
 <p>The logic used to find these &ldquo;hidden&rdquo; opposites and to navigate them is provided by implementations
 					of the
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/OppositeEndFinder.html" target="_new">
 						<code class="code">OppositeEndFinder</code>
 					</a> interface. By default, the
 					<code class="code">EcoreEnvironmentFactory</code> uses the

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/DefaultOppositeEndFinder.html" target="_new">
 						<code class="code">DefaultOppositeEndFinder</code>
 					</a> implementation. It performs the lookup of annotated references by maintaining a cache based on
 					the Ecore package registry. Successful navigation of those &ldquo;hidden&rdquo; opposites requires an

 					<a class="ulink" href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.6.0/org/eclipse/emf/ecore/util/ECrossReferenceAdapter.html" target="_new">
 						<code class="code">ECrossReferenceAdapter</code>
 					</a> to be registered for the containment hierarchy or the resource or resource set that should be used as the scope of the navigation.
 				</p>
 <p>Obviously,
 					<a class="ulink" href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.6.0/org/eclipse/emf/ecore/util/ECrossReferenceAdapter.html" target="_new">
 						<code class="code">ECrossReferenceAdapter</code>
 					</a> has a significant downside: it responds to &ldquo;hidden&rdquo; opposite navigation requests only based on what has so far been loaded by EMF. If the set of resources held by an underlying EMF storage system contains more resources than have so far been loaded into the resource set, non-loaded content from that storage system won&rsquo;t be considered by the
 					<code class="code">ECrossReferenceAdapter</code>. Given a store with reasonable search capabilities it is desirable to take advantage of these capabilities also to perform reverse navigation of those &ldquo;hidden&rdquo; opposites. To achieve this, a specific implementation of the

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/OppositeEndFinder.html" target="_new">
 						<code class="code">OppositeEndFinder</code>
 					</a> interface can be provided. It may be a specialization of

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/DefaultOppositeEndFinder.html" target="_new">
 						<code class="code">DefaultOppositeEndFinder</code>
 					</a>, e.g., when the reference lookup based on the Ecore package registry is sufficient and only the navigation behavior shall be redefined:
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">class&nbsp;MyOppositeEndFinder&nbsp;extends&nbsp;DefaultOppositeEndFinder&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;MyOppositeEndFinder(EPackage.Registry&nbsp;registry)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;super(registry);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;@Override<br>
 &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;Object&nbsp;navigateOppositeProperty(EStructuralFeature&nbsp;property,&nbsp;Object&nbsp;target)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Collection&lt;Object&gt;&nbsp;result&nbsp;=&nbsp;null;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EObject&nbsp;eTarget&nbsp;=&nbsp;(EObject)&nbsp;target;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;do&nbsp;something&nbsp;clever,&nbsp;e.g.,&nbsp;using&nbsp;your&nbsp;underlying&nbsp;store's&nbsp;query&nbsp;facility&nbsp;or<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;the&nbsp;new&nbsp;EMF&nbsp;Query2&nbsp;component&nbsp;(incubation)<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;...<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;result;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 }<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>With this, OCL can be instantiated using the custom opposite end finder as follows:</p>
 <div class="literallayout">
 <p>
 <code class="code">&nbsp;&nbsp;OCL&nbsp;ocl&nbsp;=&nbsp;OCL.newInstance(new&nbsp;EcoreEnvironmentFactoryWithHiddenOpposites(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EPackage.Registry.INSTANCE,&nbsp;new&nbsp;MyOppositeEndFinder()));<br>
 &nbsp;&nbsp;...<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>With this, when the use of a property in an OCL expression cannot be resolved to an attribute
 					or reference, the opposite end finder is asked to look for a correspondingly-named "hidden"
 					opposite. Navigation across this &ldquo;hidden&rdquo; opposite will then call the
 					<code class="code">navigateOppositeProperty</code> method on
 					<code class="code">MyOppositeEndFinder</code>.
 				</p>
 </div>
 </div>
 <div class="section" title="OCL Persistence">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Persistence"></a>OCL Persistence</h2>
 </div>
 </div>
 </div>
 <p>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.</p>
 <div class="section" title="The Type Resolver">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheTypeResolver"></a>The Type Resolver</h3>
 </div>
 </div>
 </div>
 <p>OCL defines a number of template metaclasses, including the
 					<code class="code">CollectionType</code>
 					metaclass and its specializations,
 					<code class="code">MessageType</code>, and

 					<code class="code">TupleType</code>.  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

 					<code class="code">OrderedSet(String)</code> exists and it is created on the occasion when
 					it is first needed.  Likewise, the
 					<code class="code">OclMessage</code> type for invocations
 					of the
 					<code class="code">EModelElement::getEAnnotation(EString)</code> operation and the

 					<code class="code">Tuple{a : String, b : EClass}</code> type.
 				</p>
 <p>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
 					<code class="code">def:</code> expressions.  The

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/TypeResolver.html" target="_new">
 						<code class="code">TypeResolver</code>
 					</a> API is responsible for the demand-creation of these types and for their persistence.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5170-persistence.png"></div>
 <p>

 </p>
 <p>Every
 					<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> has a
 					<code class="code">TypeResolver</code> that persists demand-created types and additional features.  For a client that doesn&rsquo;t require persistence, the
 					<code class="code">TypeResolver</code> will create a
 					<code class="code">Resource</code> with the dummy
 					<code class="code">ocl://</code> scheme (no resource factory is provided for this scheme).
 				</p>
 <p>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

 					<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&rsquo;s

 					<code class="code">newInstance(EnvironmentFactory, Resource)</code> factory method or 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&rsquo;s
 					<code class="code">load(Resource)</code> method.
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">Resource&nbsp;modelResource&nbsp;=&nbsp;getResourceSet().getResource(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;URI.createPlatformResourceURI("/models/My.ecore",&nbsp;true),&nbsp;true);<br>

 <br>
 //&nbsp;persist&nbsp;demand-created&nbsp;types&nbsp;etc.&nbsp;in&nbsp;my&nbsp;model&nbsp;resource<br>
 OCL&lt;?,&nbsp;EClassifier,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;?,&nbsp;Constraint,&nbsp;EClass,&nbsp;EObject&gt;&nbsp;ocl;<br>
 ocl&nbsp;=&nbsp;OCL.newInstance(EcoreEnvironmentFactory.INSTANCE,&nbsp;myResource);<br>

 <br>
 //&nbsp;use&nbsp;the&nbsp;OCL&nbsp;to&nbsp;parse&nbsp;constraints,&nbsp;store&nbsp;them&nbsp;in&nbsp;the&nbsp;Ecore&nbsp;model,<br>
 //	&nbsp;&nbsp;and&nbsp;save&nbsp;everything&nbsp;together&nbsp;in&nbsp;one&nbsp;resource&nbsp;for&nbsp;a&nbsp;consistent,<br>
 //&nbsp;&nbsp;&nbsp;self-contained&nbsp;OCL&nbsp;environment<br>

 <br>
 ...<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/AbstractTypeResolver.html" target="_new">
 						<code class="code">AbstractTypeResolver</code>
 					</a> 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 &ldquo;shadow&rdquo; the classifiers in which context they are defined, in
 					the manner by which the OCL specification&rsquo;s adaptation for EMOF indicates that operations
 					are to be &ldquo;owned&rdquo; by EMOF
 					<code class="code">DataType</code> s.
 				</p>
 <p>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
 					<code class="code">TypeResolver</code> implementation, a client of the OCL
 					parser can find the demand-created objects in the resolver&rsquo;s resource and relocate them
 					as needed.
 				</p>
 </div>
 </div>
 <div class="section" title="Creating Metamodel Bindings">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="AdvancedMetamodelBindings"></a>Creating Metamodel Bindings</h2>
 </div>
 </div>
 </div>
 <p>The Eclipse OCL component provides a generic specification of the OCL Abstract Syntax Model
 				plus bindings for two popular Eclipse metamodels:  Ecore and UML.  Users of the OCL API
 				can likewise create bindings for their metamodels, to integrate OCL with their modeling
 				languages.</p>
 <p>The
 				<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> interface has a generic type signature with several parameters, representing the metamodeling
 				constructs required by OCL, that it borrows from UML, EMOF, and the other metamodels that
 				it targets.  The Javadoc for that interface defines the mappings, and the same type parameter
 				names are used consistently throughout the OCL API.
 			</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5180-bindings.png"></div>
 <p>

 </p>
 <p>To provide a metamodel binding, a client must provide implementations of the following interfaces:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">Environment</code> and
 						<code class="code">EnvironmentFactory</code>, supplying suitable substitutions for the generic type parameters.  Note that not all of these are actually required; for example, Ecore does not have the concept of
 						<code class="code">State</code>, so it just substitutes
 						<code class="code">EObject</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">EvaluationEnvironment</code> for accessing properties of run-time instances of models
 					</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">UMLReflection</code> for introspecting models (instances of thetarget metamodel)
 					</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">OCLStandardLibrary</code>, providing the instances of the metamodel&rsquo;s
 						<code class="code">Classifier</code> metaclass that implement the OCL Standard Library types
 					</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">OCLFactory</code>, providing a factory for all of the metaclasses of the Abstract Syntax Model
 					</p>
 </li>
 </ul>
 </div>
 <p>This last item, above, necessitates furthermore that the metamodel binding provide a
 				concrete specialization of the Abstract Syntax Model (in its entirety) that mixes in the
 				target metamodel&rsquo;s correspondents of the UML
 				<code class="code">Classifier</code> and

 				<code class="code">TypedElement</code> metaclasses.  The former is required to provide
 				compatibility of the metaclasses in the OCL
 				<code class="code">Types</code> with the
 				target metamodel&rsquo;s type system.  The latter is required for compatibility of the metaclasses
 				in the OCL
 				<code class="code">Expressions</code> package with the target metamodel&rsquo;s
 				typed elements.
 			</p>
 <div class="section" title="The OCL Abstract Syntax Model">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheOCLAbstractSyntaxModel"></a>The OCL Abstract Syntax Model</h3>
 </div>
 </div>
 </div>
 <p>The following diagram summarizes the metaclasses of the OCL
 					<code class="code">Types</code> package:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5180-ocltypes.png"></div>
 <p>

 </p>
 <p>The following diagram summarizes the call expression metaclasses of the OCL
 					<code class="code">Expressions</code> package:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5180-callexp.png"></div>
 <p>

 </p>
 <p>The following diagram summarizes the literal expression metaclasses of the OCL
 					<code class="code">Expressions</code> package:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5180-literalexp.png"></div>
 <p>

 </p>
 <p>The following diagram summarizes the remaining metaclasses of the OCL
 					<code class="code">Expressions</code> package:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5180-miscexp.png"></div>
 <p>

 </p>
 </div>
 </div>
 <div class="section" title="Incrementally Re-Evaluating OCL Expressions Using the Impact Analyzer">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="ImpactAnalyzer"></a>Incrementally Re-Evaluating OCL Expressions Using the Impact Analyzer</h2>
 </div>
 </div>
 </div>
 <p>When Ecore metamodels use many OCL invariants and the models constrained by these invariants
 				grow large, re-evaluating the invariants becomes a performance challenge. As OCL expressions
 				can navigate freely across resource boundaries, changes to a model element in one resource
 				can easily affect invariants for model elements in other resources. To reliably catch all
 				invalidated constraints after a change it would be necessary to re-evaluate all invariants
 				on all their context objects regardless their resource. This does not scale sufficiently well.</p>
 <p>The
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/examples/impactanalyzer/ImpactAnalyzerFactory.html" target="_new">
 					<code class="code">ImpactAnalyzerFactory</code>
 				</a> interface allows tool builders to efficiently determine a much smaller set of model elements on which re-evaluation of expressions is necessary after a change.
 			</p>
 <p>Given an
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/OCLExpression.html" target="_new">OCL expression</a>, the factory can be used to create an impact analyzer for a single expression as follows:
 			</p>
 <div class="literallayout">
 <p>
 <code class="code">final&nbsp;OCLExpression&nbsp;e&nbsp;=&nbsp;...;<br>
 final&nbsp;ImpactAnalyzer&nbsp;impactAnalyzer&nbsp;=<br>
 		ImpactAnalyzerFactory.INSTANCE.createImpactAnalyzer(<br>
 &nbsp;&nbsp;&nbsp;&nbsp;			e,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;the&nbsp;expression&nbsp;to&nbsp;re-evaluate&nbsp;incrementally<br>
 &nbsp;&nbsp;&nbsp;&nbsp;			false,&nbsp;&nbsp;//&nbsp;whether&nbsp;to&nbsp;re-evaluate&nbsp;when&nbsp;new&nbsp;context&nbsp;objects&nbsp;appear<br>
 &nbsp;&nbsp;&nbsp;&nbsp;			OCLFactory.INSTANCE);<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The impact analyzer obtained this way can create a change notification filter which
 				can then be used to register for notifications that indicate a change which may affect
 				the value of the expression. Consider the following example:</p>
 <div class="literallayout">
 <p>
 <code class="code">ResourceSet&nbsp;myResourceSet&nbsp;=&nbsp;...;<br>
 EventFilter&nbsp;filter&nbsp;=&nbsp;impactAnalyzer.createFilterForExpression();<br>
 EventManager&nbsp;eventManager&nbsp;=<br>
 	EventManagerFactory.eINSTANCE.getEventManagerFor(myResourceSet);<br>
 eventManager.subscribe(filter,&nbsp;new&nbsp;AdapterImpl()&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;public&nbsp;void&nbsp;notifyChanged(Notification&nbsp;notification)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Collection&lt;EObject&gt;&nbsp;valueMayHaveChangedOn&nbsp;=<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;impactAnalyzer.getContextObjects(notification);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for&nbsp;(EObject&nbsp;eo&nbsp;:&nbsp;valueMayHaveChangedOn)&nbsp;{<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	//&nbsp;...&nbsp;perform&nbsp;some&nbsp;re-evaluation&nbsp;action&nbsp;of&nbsp;e&nbsp;for&nbsp;context&nbsp;eo&nbsp;here<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br>
 &nbsp;&nbsp;&nbsp;&nbsp;}<br>
 });<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>The event manager can be used to register the event filters of several OCL expressions with their respective
 				adapters. The adapters for different expressions do not have to be distinct but may optionally be shared. The
 				following figure shows how the classes relate, as a UML class diagram:</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5190-impact-analyzer-classes.png"></div>
 <p>

 </p>
 <p>For each OCL expression a new impact analyzer is used. The event filters produced by them can be registered
 				with the same event manager. The following figure shows a typical instance collaboration diagram in UML
 				notation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5190-impact-analyzer-instances.png"></div>
 <p>

 </p>
 <p>The
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/examples/eventmanager/EventManagerFactory.html" target="_new">event manager factory</a> and the
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/examples/eventmanager/EventManager.html" target="_new">event managers</a> it produces lay the scalable foundation for the re-evaluation process. Even if it has to manage many subscriptions, its performance does not degrade as it would if the change notification filters were evaluated one after the other. With this it becomes possible to register many OCL expressions for change impact analysis as shown above. The figure below shows a typical default configuration of an event manager, as a UML instance collaboration diagram.
 			</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5190-event-manager-default-config.png"></div>
 <p>

 </p>
 <p>The event manager in the figure is configured to listen to the change events coming
 				from anything inside the resource set. In this example it is shown with three different
 				event filters, each coming with its own adapter handling those change notifications
 				matches by the respective filter.</p>
 <p>As described in more detail in the Javadoc, event managers may be re-used,
 				temporarily deactivated and new ones may be created specifically upon request. This way
 				it is possible to have several event managers, e.g., listening for changes during different
 				phases of a model&rsquo;s life cycle without having to create and initialize the event managers
 				again and again. Also, an event manager is not restricted to listen to the changes of
 				exactly one resource set. The following figure shows a not so typical configuration, again as a
 				UML instance collaboration diagram.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/5190-event-manager-instances.png"></div>
 <p>

 </p>
 <div class="section" title="Using the Impact Analyzer in EMF Editors">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="UsingtheImpactAnalyzerinEMFEditors"></a>Using the Impact Analyzer in EMF Editors</h3>
 </div>
 </div>
 </div>
 <p>The
 					<code class="code">org.eclipse.ocl.examples.impactanalyzer.ui</code> package provides experimental support
 					for embedding the impact analyzer in EMF editors. Adding the lines
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">@SuppressWarnings("unused")&nbsp;			//&nbsp;not&nbsp;read;&nbsp;just&nbsp;used&nbsp;to&nbsp;avoid&nbsp;GC&nbsp;&nbsp;<br>
 private&nbsp;Revalidator&nbsp;revalidator;		//&nbsp;&nbsp;from&nbsp;collecting&nbsp;re-validator<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>to the field declarations of an editor class, and adding the lines</p>
 <div class="literallayout">
 <p>
 <code class="code">revalidator&nbsp;=&nbsp;new&nbsp;Revalidator(editingDomain,&nbsp;OCLFactory.INSTANCE,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DefaultOppositeEndFinder.getInstance(),<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MyMetamodelEcorePackage.eINSTANCE);<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>at the end of the editor class&rsquo;s
 					<code class="code">createModel()</code> method turns on this experimental
 					support for the respective editors. Consequently, changes in the editor&rsquo;s
 					<code class="code">ResourceSet</code>
 					will trigger the re-evaluation of the affected invariants on the set of context objects
 					determined by the impact analyzer. Error markers of successfully validated constraints will
 					be removed, markers for invalid constraints are produced. As is obvious also from the

 					<code class="code">examples</code> part of the package name, this is not yet production-ready code. It
 					may change or disappear without notice.
 				</p>
 </div>
 <div class="section" title="Algorithm Outline">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="AlgorithmOutline"></a>Algorithm Outline</h3>
 </div>
 </div>
 </div>
 <p>The basic idea on which the impact analyzer&rsquo;s algorithm is based is this: take the EMF
 					change notification and see which elementary subexpressions, such as property call expressions,
 					are immediately affected by the change. From these pairs of
 					<code class="code">(subexpression, model element)</code>
 					it is possible to walk the expression tree and navigate &ldquo;backwards&rdquo; from the model element
 					to the candidates for the
 					<code class="code">self</code> variable for which the subexpression
 					may evaluate to the model element indicated by the notification.
 					Recursive operation calls and general
 					<code class="code">-&gt;iterate(...)</code> expressions complicate
 					matters and lead to a recursive algorithm for the impact analysis.
 				</p>
 <p>It is permissible to use calls to OCL-specified operations. The impact analyzer will trace
 					changes considering the called operation&rsquo;s body expression.</p>
 <p>The use of
 					<code class="code">allInstances</code> inside an expression may be nasty for analyzing the
 					impact of a change because then it may no longer be possible to trace the change back to
 					the possible values for
 					<code class="code">self</code>. In those cases the impact analyzer will simply
 					&ldquo;give up&rdquo; and return a collection of all instances of the expression&rsquo;s context type and
 					its subtypes.
 				</p>
 </div>
 <div class="section" title="Impact Analyzer Configuration, Scopes">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ImpactAnalyzerConfigurationScopes"></a>Impact Analyzer Configuration, Scopes</h3>
 </div>
 </div>
 </div>
 <p>The impact analyzer can be created in several different configurations as explained in
 					detail in the
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/examples/impactanalyzer/ImpactAnalyzerFactory.html" target="_new">Javadocs</a> . Particularly noteworthy is the relationship between the
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/opposites/OppositeEndFinder.html" target="_new">
 						<code class="code">OppositeEndFinder</code>
 					</a> and the way an
 					<code class="code">allInstance</code> expression is evaluated. Both depend on a notion of lookup
 					<code class="code">scope</code>. EMF does not provide any particular rules or conventions in this regard other than assuming that what has been loaded into a
 					<code class="code">ResourceSet</code> is what tools can see. While this is a working procedure for forward navigation, it doesn&rsquo;t help in defining a scope for
 					<code class="code">allInstances</code> and reverse navigation when there is no explicit opposite property.
 				</p>
 <p>For this purpose, Eclipse OCL has introduced the
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/ecore/opposites/OppositeEndFinder.html" target="_new">
 						<code class="code">OppositeEndFinder</code>
 					</a> interface through which reverse navigations
 					of references and
 					<code class="code">allInstances</code> lookups can be performed. Its default implementation
 					is based on the EMF default which is to consider the contents of a
 					<code class="code">ResourceSet</code> the
 					universe. Other implementations are possible, however, such as one that uses
 					EMF Query2 to perform the necessary lookups.
 				</p>
 <p>A default OCL evaluator will always use the current
 					<code class="code">ResourceSet</code> to determine
 					the set of all instances of a type. If a client has used an opposite end finder that implements
 					a certain lookup strategy then the default
 					<code class="code">allInstances</code> evaluation is most likely
 					inconsistent with the scope definitions of that opposite end finder. To avoid such problems,
 					a
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/examples/impactanalyzer/util/OCL.html" target="_new">specific OCL factory</a> can create OCL instances that ensure consistency between opposite navigation and
 					<code class="code">allInstances</code> evaluation.
 				</p>
 <p>Other configuration options (see
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/examples/impactanalyzer/configuration/ActivationOption.html)" target="_new">
 						<code class="code">ActivationOption</code>
 					</a> concern the specific algorithm used for tracing back from a change notification to the set of context objects for which the expression
 					may have changed its value. The default selection has proven to be the fastest for a set
 					of benchmarks. However, mileage may vary, and we&rsquo;d like to encourage users to experiment
 					also with the non-default configurations.
 				</p>
 </div>
 </div>
 <div class="section" title="Delegates">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Delegates"></a>Delegates</h2>
 </div>
 </div>
 </div>
 <p>EMF provides three delegation mechanisms that enable functionality not directly supported by EMF to be delegated to a technology that can support it.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>a
 						<a class="link" href="#ValidationDelegate" title="Validation Delegates">Validation Delegate</a> supports checking additional invariants on an EClassifier
 					</p>
 </li>
 <li class="listitem">
 <p>a
 						<a class="link" href="#SettingDelegate" title="Setting Delegates">Setting Delegate</a> supports getting an initial or derived computed value for an EStructuralFeature
 					</p>
 </li>
 <li class="listitem">
 <p>an
 						<a class="link" href="#InvocationDelegate" title="Invocation Delegates">Invocation Delegate</a> supports the execution of a function defined by an EOperation
 					</p>
 </li>
 </ul>
 </div>
 <p>and also</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>a
 						<a class="link" href="#QueryDelegate" title="Query Delegates">Query Delegate</a> supports the execution of a function not defined by an EOperation
 					</p>
 </li>
 </ul>
 </div>
 <p>When you use the
 				<a class="link" href="#OCLinEcore" title="The OCLinEcore Language">OCLinEcore</a> editor, the required EAnnotations to support delegation are provided automatically. This section provides sufficient detail to allow them to be maintained manually using the Sample Ecore Editor or Java code.
 			</p>
 <p>These EAnnotations ensure that delegates can be used for both genmodeled and reflective models.  The use of genmodel to generate Java classes for your metamodel has significant performance benefits for modeling, but currently makes little difference for OCL execution. The use of genmodel has the disadvantage that you must install the Java classes and so the user of the Java classes must run in a different Eclipse or standalone session to the developer. Conversely, using reflective models allows both developer and user to share the same Eclipse session.</p>
 <div class="section" title="GenModel Settings">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="GenModelSettings"></a>GenModel Settings</h3>
 </div>
 </div>
 </div>
 <p>There is one GenModel setting that needs to be correctly set to ensure that OCL within generated Java classes can successfully be invoked by itself. Make sure that support for reflective operation invocation is generated by setting the
 					<code class="code">Operation Reflection</code> option to
 					<code class="code">true</code>.
 				</p>
 </div>
 <div class="section" title="OCL Delegate URIs">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLDelegateURI"></a>OCL Delegate URIs</h3>
 </div>
 </div>
 </div>
 <p>Each application implementing delegation has an associated Delegate URI, which is</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL</code> for the classic evaluator
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot</code> for the Pivot evaluator
 						</p>
 </li>
 </ul>
 </div>
 <p>Only the
 					<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL</code> was available in the Helios release and so the Helios release of the OCLinEcore editor used that URI.
 				</p>
 <p>The OCLinEcore editor uses the Pivot metamodel which is more accurate and OMG compliant and so in the Indigo release, the OCLinEcore editor uses the
 					<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot</code> URI and converts all incoming usage of
 					<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL</code> URI to
 					<code class="code">http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot</code>.
 				</p>
 <p>As described in
 					<a class="link" href="#EclipseOCLs" title="The two Eclipse OCLs">The two Eclipse OCLs</a> the Pivot evaluator uses an intermediate Pivot model to hide Ecore and UML2 and so allow full OMG-compliance. The Pivot evaluator is only available when the OCL Examples and Editors feature has been installed as described in
 					<a class="link" href="#Installation" title="Installing the Eclipse OCL Examples and Editors">Installation</a>.
 				</p>
 <p>The OCL Delegate URIs are registered using the</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>org.eclipse.emf.ecore.invocation_delegate</p>
 </li>
 <li class="listitem">
 <p>org.eclipse.emf.ecore.setting_delegate</p>
 </li>
 <li class="listitem">
 <p>org.eclipse.emf.ecore.query_delegate</p>
 </li>
 <li class="listitem">
 <p>org.eclipse.emf.ecore.validation_delegate</p>
 </li>
 </ul>
 </div>
 <p>extension points. </p>
 </div>
 <div class="section" title="Standalone Initialization">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="StandaloneInitialization"></a>Standalone Initialization</h3>
 </div>
 </div>
 </div>
 <p>The initialization code for standalone usage of EMF delegates is given in the
 					<a class="link" href="#Standalone" title="Ecore/UML Standalone Configuration">Standalone</a> section.
 				</p>
 </div>
 <div class="section" title="Invocation Delegates">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="InvocationDelegate"></a>Invocation Delegates </h3>
 </div>
 </div>
 </div>
 <p>An invocation delegate is invoked to execute the body of an EOperation. An invocation delegate must be registered for the EPackage of the EClassifier of the EOperation.</p>
 <p>The EPackage registration is provided by an EAnnotation on the EPackage</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">source</code> =
 							<code class="code">http://www.eclipse.org/emf/2002/Ecore</code>

 </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>

 <code class="code">key</code> =
 									<code class="code">invocationDelegates</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">value</code> =
 									<span class="emphasis"><em>
 										<code class="code">OCL-Delegate-URI</code>
 									</em></span>

 </p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>The invocation delegate is provided by an EAnnotation on the EOperation</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">source</code> =
 							<span class="emphasis"><em>
 								<code class="code">OCL-Delegate-URI</code>
 							</em></span>

 </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>

 <code class="code">key</code> =
 									<code class="code">body</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">value</code> =
 									<span class="emphasis"><em>
 										<code class="code">OCL-expression</code>
 									</em></span>

 </p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>The
 					<span class="emphasis"><em>
 						<code class="code">OCL-expression</code>
 					</em></span> is evaluated to provide the EOperation value with the containing EClassifier as the
 					<code class="code">self</code> context object and the EParameters accessible as parameters from OCL. The return type of the
 					<span class="emphasis"><em>
 						<code class="code">OCL-expression</code>
 					</em></span> must conform to the return type of the EOperation.
 				</p>
 </div>
 <div class="section" title="Setting Delegates">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="SettingDelegate"></a>Setting Delegates </h3>
 </div>
 </div>
 </div>
 <p>A setting delegate is invoked to provide the initial or derived value of an EStructuralFeature.  A setting delegate must be been registered for the EPackage of the EClassifier of the EStructuralFeature.</p>
 <p>The EPackage registration is provided by an EAnnotation on the EPackage</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">source</code> =
 							<code class="code">http://www.eclipse.org/emf/2002/Ecore</code>

 </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>

 <code class="code">key</code> =
 									<code class="code">settingDelegates</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">value</code> =
 									<span class="emphasis"><em>
 										<code class="code">OCL-Delegate-URI</code>
 									</em></span>

 </p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>The setting delegate is provided by an EAnnotation on the EStructuralFeature</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">source</code> =
 							<span class="emphasis"><em>
 								<code class="code">OCL-Delegate-URI</code>
 							</em></span>

 </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>

 <code class="code">key</code> =
 									<code class="code">derivation</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">value</code> =
 									<span class="emphasis"><em>
 										<code class="code">OCL-expression</code>
 									</em></span>

 </p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>The
 					<span class="emphasis"><em>
 						<code class="code">OCL-expression</code>
 					</em></span> is evaluated to provide the EStructuralFeature value with the containing EClassifier as the
 					<code class="code">self</code> context object. The result type of the
 					<span class="emphasis"><em>
 						<code class="code">OCL-expression</code>
 					</em></span> must conform to the type of the EStructuralFeature.
 				</p>
 <p>An
 					<code class="code">initial</code> rather than
 					<code class="code">derivation</code> value may be specified. The
 					<code class="code">initial</code> is ignored if a
 					<code class="code">derivation</code> is also specified.
 				</p>
 </div>
 <div class="section" title="Validation Delegates">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ValidationDelegate"></a>Validation Delegates</h3>
 </div>
 </div>
 </div>
 <p>A validation delegate is invoked to provide additional validation of an EClassifier. A validation delegate must be registered for the EPackage of the EClassifier for which the EClassifier provides any Ecore invariants or Ecore constraints.  Both Ecore constraints and invariants constrain an EClassifier, the difference is that an Ecore invariant is realised by an EOperation and so an Ecore invariant may be re-used by modeling environments that may wish to selectively check or re-check constraints.</p>
 <p>The EPackage registration is provided by an EAnnotation on the EPackage</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">source</code> =
 							<code class="code">http://www.eclipse.org/emf/2002/Ecore</code>

 </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>

 <code class="code">key</code> =
 									<code class="code">validationDelegates</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">value</code> =
 									<span class="emphasis"><em>
 										<code class="code">OCL-Delegate-URI</code>
 									</em></span>

 </p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>All Ecore constraints must be listed in an EAnnotation on the EClassifier</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">source</code> =
 							<code class="code">http://www.eclipse.org/emf/2002/Ecore</code>

 </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>

 <code class="code">key</code> =
 									<code class="code">constraints</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">value</code> =
 									<span class="emphasis"><em>
 										<code class="code">constraintName1 constraintName2 constraintName3</code>
 									</em></span>

 </p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>The validation delegate for each Ecore constraint is provided by a further EAnnotation on the EClassifier</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">source</code> =
 							<span class="emphasis"><em>
 								<code class="code">OCL-Delegate-URI</code>
 							</em></span>

 </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>

 <code class="code">key</code> =
 									<span class="emphasis"><em>
 										<code class="code">constraintName</code>
 									</em></span>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">value</code> =
 									<span class="emphasis"><em>
 										<code class="code">OCL-expression</code>
 									</em></span>

 </p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>The validation delegate for each Ecore invariant is provided by an EAnnotation on the EOperation</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">source</code> =
 							<span class="emphasis"><em>
 								<code class="code">OCL-Delegate-URI</code>
 							</em></span>

 </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>

 <code class="code">key</code> =
 									<code class="code">body</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">value</code> =
 									<span class="emphasis"><em>
 										<code class="code">OCL-expression</code>
 									</em></span>

 </p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>The
 					<span class="emphasis"><em>
 						<code class="code">OCL-expression</code>
 					</em></span> is evaluated to validate the EClassifier with the EClassifier as the
 					<code class="code">self</code> context object. The result type of the
 					<span class="emphasis"><em>
 						<code class="code">OCL-expression</code>
 					</em></span> must be Boolean.
 				</p>
 </div>
 <div class="section" title="Validation Messages">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ValidationMessages"></a>Validation Messages</h3>
 </div>
 </div>
 </div>
 <p>When a validation fails EMF generates a default diagnostic of the form
 					<code class="code">The</code>
 					<span class="emphasis"><em>
 						<code class="code">'constraintName'</code>
 					</em></span>
 					<code class="code">is violated on</code>
 					<span class="emphasis"><em>
 						<code class="code">'constrainedObject'</code>
 					</em></span>.
 				</p>
 <p>If the
 					<a class="link" href="#OCLinEcoreEObjectValidator" title="OCLinEcoreEObjectValidator">OCLinEcoreEObjectValidator</a> or
 					<a class="link" href="#CompleteOCLEObjectValidator" title="CompleteOCLEObjectValidator">CompleteOCLEObjectValidator</a> are used a custom message may be supplied using an additional EAnnotation on the EClassifier.
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">source</code> =
 							<span class="emphasis"><em>
 								<code class="code">OCL-Delegate-URI</code>
 							</em></span>

 </p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>

 <code class="code">key</code> =
 									<span class="emphasis"><em>
 										<code class="code">constraintName</code>
 									</em></span>
 									<code class="code">$message</code>

 </p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">value</code> =
 									<span class="emphasis"><em>
 										<code class="code">OCL-expression</code>
 									</em></span>

 </p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>The
 					<span class="emphasis"><em>
 						<code class="code">OCL-expression</code>
 					</em></span> is evaluated to produce the custom message with the EClassifier as the
 					<code class="code">self</code> context object. The result type of the
 					<span class="emphasis"><em>
 						<code class="code">OCL-expression</code>
 					</em></span> must be String.
 				</p>
 <p>The severity of the diagnostic can also be customized by exploiting the four values of the Boolean value of the constraint evaluation.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">true</code> indicates successful validation
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">false</code> indicates unsuccessful validation with warning severity
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">null</code> indicates unsuccessful validation with error severity
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">invalid</code> indicates a failure to perform validation (error severity)
 						</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="section" title="Query Delegates">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="QueryDelegate"></a>Query Delegates </h3>
 </div>
 </div>
 </div>
 <p>A query delegate is invoked to evaluate a parameterized query on a EObject for which there is no corresponding EOperation. A query delegate is registered to install this query and allow its compiled form to be cached. The delegate may then be invoked as many times as required for compatible context objects and parameters.</p>
 <p>This facility enables an EMF application to execute OCL without declaring or instantiating any OCL classes.</p>
 <p>The query delegate registration is analogous to direct use of
 					<code class="code">OCL.newInstance().createHelper().createQuery()</code>

 </p>
 <p>The query delegate execution is analogous to

 					<code class="code">OCL.evaluate()</code>

 </p>
 </div>
 </div>
 <div class="section" title="Ecore/UML Standalone Configuration">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Standalone"></a>Ecore/UML Standalone Configuration</h2>
 </div>
 </div>
 </div>
 <p>If you use Eclipse OCL within Eclipse you should find that the appropriate registrations are provided for you automatically by the plugin registration mechanisms.</p>
 <p>However if you use Eclipse OCL outside Eclipse, for instance in JUnit tests, you must provide the corresponding registrations in your code.</p>
 <div class="section" title="Ecore">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Ecore"></a>Ecore</h3>
 </div>
 </div>
 </div>
 <p>For the Ecore metamodel, the required registrations should be provided by invoking

 					<code class="code">org.eclipse.ocl.ecore.OCL.initialize(ResourceSet)</code>.
 				</p>
 <p>This may be invoked with a null argument to install the registrations in the global EPackage.Registry. This is not normally recommended, but since this is for your application, the integrity of the global registry is your responsibility.</p>
 <p>It is normally recommended to install the registrations solely for use in your own ResourceSet and to pass that to the initialize routine.</p>
 <p>This initialization ensures that *.ecore is understood.</p>
 <p>If you want to use EMF delegates to dispatch OCL, the required registrations may be
 					provided by
 					<code class="code">org.eclipse.ocl.ecore.delegate.OCLDelegateDomain.initialize(ResourceSet)</code>.
 				</p>
 <p>This may be invoked with a null argument to install the registrations in the global EPackage.Registry rather than a specified local registry. </p>
 </div>
 <div class="section" title="UML">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="UML"></a>UML</h3>
 </div>
 </div>
 </div>
 <p>For the UML metamodel, the required registrations should be provided in a similar way by invoking

 					<code class="code">org.eclipse.ocl.uml.OCL.initialize(ResourceSet)</code>.
 				</p>
 <p>This initialization ensures that *.uml is understood that  http://www.eclipse.org/ocl/1.1.0/oclstdlib.uml is known and that standard pathmap: locations are resolvable. It also invokes
 					<code class="code">org.eclipse.uml2.uml.resources.util.UMLResourcesUtil.init(ResourceSet)</code> to ensure that all Eclipse and OMG UML namespaces and extensions are registered..
 				</p>
 </div>
 <div class="section" title="Xtext Editors">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="XtextEditors"></a>Xtext Editors</h3>
 </div>
 </div>
 </div>
 <p>The Xtext Editors use the Pivot binding and so their initialiation is described in &ldquo;Pivot Standalone Configuration&rdquo;#PivotStandalone.</p>
 <p>The Xtext editors may be used with the Ecore or UML bindings in so far as the Complete OCL editor provides a *.ocl document that may be parsed by the LPG parser, and the OCLinEcore editor provides embedded OCL that may be executed by either evaluator.</p>
 </div>
 </div>
 </div>
 <div class="chapter" title="Chapter&nbsp;7.&nbsp;Unified or Pivot Programmers Guide">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title">
 <a name="PivotProgrammersGuide"></a>Chapter&nbsp;7.&nbsp;Unified or Pivot Programmers Guide</h2>
 </div>
 </div>
 </div>
 <p>The Unified or Pivot Programmers Guide describes the ways in which the Pivot binding Eclipse OCL can be used from Java programs.</p>
 <p>The Pivot binding was first available as an examples quality prototype in 3.1.0 (Indigo). The Pivot binding
 			became the preferred binding in 6.0.0 (Mars). The older Ecore and UML bindings are described in a separate
 			<a class="link" href="#ProgrammersGuide" title="Chapter&nbsp;6.&nbsp;Classic Ecore/UML Programmers Guide">Ecore/UML Programmers Guide</a>.
 		</p>
 <p>The OCL Parser/Interpreter provides an implementation of the
 			<a class="ulink" href="http://www.omg.org/spec/OCL" target="_new">Object Constraint Language 2.4</a> specification for EMF-based metamodels and models.  It offers OCL
 			constraint and query parsing and evaluation, model-based validation, and
 			provides an infrastructure for content assist in textual editors.
 		</p>
 <p>The following features are supported in the current version:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Classifier invariant constraints</p>
 </li>
 <li class="listitem">
 <p>Operation precondition and postcondition constraints and body conditions</p>
 </li>
 <li class="listitem">
 <p>Property constraints (initial-value and derivation)</p>
 </li>
 <li class="listitem">
 <p>Attribute and operation definitions (def: expressions)</p>
 </li>
 <li class="listitem">
 <p>Package context declaration</p>
 </li>
 <li class="listitem">
 <p>Basic values and types</p>
 </li>
 <li class="listitem">
 <p>Collection types</p>
 </li>
 <li class="listitem">
 <p>Navigation of attributes and association ends</p>
 </li>
 <li class="listitem">
 <p>Operation invocation</p>
 </li>
 <li class="listitem">
 <p>Iteration expressions (all standard iterators)</p>
 </li>
 <li class="listitem">
 <p>Let expressions</p>
 </li>
 <li class="listitem">
 <p>If expressions</p>
 </li>
 <li class="listitem">
 <p>Tuples</p>
 </li>
 <li class="listitem">
 <p>Message expressions, including unspecified values</p>
 </li>
 <li class="listitem">
 <p>Operations predefined by OCL:  allInstances(), oclIsKindOf(), oclIsTypeOf(), oclAsType(), oclIsNew()</p>
 </li>
 <li class="listitem">
 <p>Escape syntax for illegal names:  type, operation, attribute, etc. names that correspond to OCL reserved words can be escaped in the standard fashion using a leading underscore (&lsquo;_&rsquo;).  In addition, names that contain spaces or tabs can be escaped by enclosing them in double-quotes (&lsquo;"&rsquo;; this is non-standard).  e.g.,
 					<code class="code">self.ownedRule-&gt;forAll(c : Constraint | c._context = self)</code>

 </p>
 </li>
 </ul>
 </div>
 <p>The above constructs are supported by the parser for parsing and
 			for evaluation, with the exception of the oclIsNew() operation and
 			message expressions.  All of the above are supported for both Ecore
 			and UML models.  The following are supported by default for UML
 			(both in parsing and evaluation):</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Navigation of non-navigable association ends (including those that are owned by the association)</p>
 </li>
 <li class="listitem">
 <p>Qualified association end navigation</p>
 </li>
 <li class="listitem">
 <p>Navigation to association classes, including source qualifiers</p>
 </li>
 <li class="listitem">
 <p>Operations predefined by OCL: oclIsInState()</p>
 </li>
 </ul>
 </div>
 <p>The following features are provided in addition to the OCL specification:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>String case conversion operations:  toUpper(), toLower()</p>
 </li>
 <li class="listitem">
 <p>Support for comparison (&lt;, &lt;=, etc.) and sorting of any java
 					<code class="code">Comparable</code> s of conformant types
 				</p>
 </li>
 <li class="listitem">
 <p>Transitive closure of associations:  closure(expr : OCLExpression) iterator</p>
 </li>
 <li class="listitem">
 <p>Navigation of &ldquo;hidden&rdquo; opposites of references specified in Ecore models using a
 					<code class="code">Property.oppositeRoleName</code> annotation with source
 					<code class="code">http://schema.omg.org/spec/MOF/2.0/emof.xml</code> on the forward reference, producing an
 					<code class="code">OppositePropertyCallExp</code> expression
 				</p>
 </li>
 </ul>
 </div>
 <p>The OCL implementation is defined in plug-ins for convenient deployment in
 			Eclipse, but as is the case for EMF, it can also be used stand-alone.  The
 			plug-ins are partitioned thus:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">org.eclipse.ocl.domain</code>:  the neutral Pivot model interfaces.
 				</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">org.eclipse.ocl.pivot</code>:  the neutral Pivot model and evaluator.
 				</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">org.eclipse.ocl.library</code>:  the extensible OCL Stndard Library.
 				</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">org.eclipse.ocl.examples.codegen</code>:  the OCL to Java code generator.
 				</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">org.eclipse.ocl.examples.debug...</code>:  the extensible debugger.
 				</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">org.eclipse.ocl.examples.validity</code>:  the Validation View.
 				</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">org.eclipse.ocl.examples.xtext...</code>:  Xtext editors.
 				</p>
 </li>
 </ul>
 </div>
 <div class="section" title="Validators">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Validators"></a>Validators</h2>
 </div>
 </div>
 </div>
 <p>When using the Pivot metamodel, there are two specialized validators available to support integration of OCL in to a larger Ecore environment. </p>
 <div class="section" title="OCLinEcoreEObjectValidator">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLinEcoreEObjectValidator"></a>OCLinEcoreEObjectValidator</h3>
 </div>
 </div>
 </div>
 <p>Unfortunately, in the Indigo release, EMF does not support this customization and so must be activated by explicitly using an EValidator that is aware of the ValidationDelegateExtension extended API. This is available by using the OCLinEcoreEObjectValidator, which you may install globally by:</p>
 <div class="literallayout">
 <p>
 <code class="code">EValidator.Registry.INSTANCE.put(null,&nbsp;new&nbsp;OCLinEcoreEObjectValidator());<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>or more selectively by adjusting the inheritance of the Validator class generated by EMF from (for a model of a Company):</p>
 <div class="literallayout">
 <p>
 <code class="code">import&nbsp;org.eclipse.emf.ecore.util.EObjectValidator;<br>

 <br>
 /**<br>
 &nbsp;*&nbsp;&lt;!--&nbsp;begin-user-doc&nbsp;--&gt;<br>
 &nbsp;*&nbsp;The&nbsp;&lt;b&gt;Validator&lt;/b&gt;&nbsp;for&nbsp;the&nbsp;model.<br>
 &nbsp;*&nbsp;&lt;!--&nbsp;end-user-doc&nbsp;--&gt;<br>
 &nbsp;*&nbsp;@see&nbsp;company.CompanyPackage<br>
 &nbsp;*/<br>
 public&nbsp;class&nbsp;CompanyValidator&nbsp;extends&nbsp;EObjectValidator&nbsp;{<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>to</p>
 <div class="literallayout">
 <p>
 <code class="code">import&nbsp;org.eclipse.ocl.xtext.oclinecore.validation.OCLinEcoreEObjectValidator;<br>

 <br>
 /**<br>
 &nbsp;*&nbsp;&lt;!--&nbsp;begin-user-doc&nbsp;--&gt;<br>
 &nbsp;*&nbsp;The&nbsp;&lt;b&gt;Validator&lt;/b&gt;&nbsp;for&nbsp;the&nbsp;model.<br>
 &nbsp;*&nbsp;&lt;!--&nbsp;end-user-doc&nbsp;--&gt;<br>
 &nbsp;*&nbsp;@see&nbsp;company.CompanyPackage<br>
 &nbsp;*&nbsp;@generated&nbsp;not<br>
 &nbsp;*/<br>
 public&nbsp;class&nbsp;CompanyValidator&nbsp;extends&nbsp;OCLinEcoreEObjectValidator&nbsp;{<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>Note the
 					<span class="bold"><strong>@generated not</strong></span> that indicates that the class interface is manually defined. Do not use
 					<span class="bold"><strong>@generated NOT</strong></span> since that indicates that the whole class is manually defined.
 				</p>
 </div>
 <div class="section" title="CompleteOCLEObjectValidator">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CompleteOCLEObjectValidator"></a>CompleteOCLEObjectValidator</h3>
 </div>
 </div>
 </div>
 <p>The CompleteOCLEObjectValidator is used to enable Complete OCL documents to participate in the validation processing of an Xtext editor.</p>
 <p>The APIs for merging Complete OCL and Ecore as intermediate Pivots and then migrating the Pivot back to Ecore are experimental.</p>
 </div>
 </div>
 <div class="section" title="The Pivot Evaluator">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="PivotEvaluator"></a>The Pivot Evaluator</h2>
 </div>
 </div>
 </div>
 <p>The Pivot evaluator is a complete reimplementation of the classic evaluator to exploit experience and the Pivot metamodel</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>numeric growth beyond 32/64 bits is accommodated</p>
 </li>
 <li class="listitem">
 <p>equal numbers are equal regardless of type</p>
 </li>
 <li class="listitem">
 <p>templated types are supported</p>
 </li>
 <li class="listitem">
 <p>library operations are modeled and extensible</p>
 </li>
 <li class="listitem">
 <p>oclType() returns a Class offering full reflection without loss of static typing</p>
 </li>
 <li class="listitem">
 <p>optimised virtual function dispatch tables</p>
 </li>
 <li class="listitem">
 <p>code generation to Java</p>
 </li>
 </ul>
 </div>
 <p>The APIs of the two evaluators are very similar since Ecore compatibility is very important. For basic OCL evaluation, users should not notice any functional difference between the two evaluators. The Pivot evaluator is generally between 2 and 5 times faster as well as being more accurate. The code generated evaluation may be a further 20 times faster.</p>
 <div class="section" title="The Evolving Pivot Value System">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="PivotValue-History"></a>The Evolving Pivot Value System</h3>
 </div>
 </div>
 </div>
 <p>The classic evaluator uses Ecore and Java library representations such as EObject, Integer, String and Set directly for evaluation. This avoids conversion costs but incurs OCL accuracy challenges for numeric equality and growth.</p>
 <p>The Juno release of the Pivot evaluator use polymorphic
 					<code class="code">Value</code> representations such as EObjectValue, IntegerValue, StringValue and SetValue. This avoids the OCL accuracy difficulties but requires wrapper objects and incurs conversion costs wherever a compatible Ecore API is in use.
 				</p>
 <p>The IntegerValue and RealValue classes avoid the equivalence and accuracy problems of Integer and Double by implementing Object.equals(Object) with OCL semantics.</p>
 <p>The costs of the polymorphic Boolean, String and EObject wrappers became apparent when testing the code generator and so the Kepler and Luna releases use a hybrid representation. Unboxed values (the natural Ecore and Java representation) are used wherever OCL and Java have compatible semantics, that is for Boolean, String, null, invalid/exception and EObjects that are not Types. Boxed polymorphic value representations are used wherever OCL and Java semantics differ, that is for IntegerValue, RealValue, CollectionValue, TupleValue and TypeValue. This avoids unnecessary conversion costs, but requires many instanceof tests to compensate for the lack of Value polymorphism. When generating code, static analysis can often eliminate many of the instanceof cases and so the hybrid representation is faster.</p>
 </div>
 <div class="section" title="The Pivot Value System">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="PivotValues"></a>The Pivot Value System</h3>
 </div>
 </div>
 </div>
 <p>Every value has a unique type identity supervised by the
 					<code class="code">IdManager</code> class. This unique identity can be shared by multiple OCL applications that may have distinct type systems as a result of Complete OCL complements.
 				</p>
 <p>Every value has a type that is determined from its type identity by a type-system-specific
 					<code class="code">IdResolver</code> instance, which also supports conversion between boxed and unboxed value representations.
 				</p>
 <div class="section" title="Value Conversions">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="PivotValueConversions"></a>Value Conversions</h4>
 </div>
 </div>
 </div>
 <p>The values are managed by a
 						<code class="code">ValueFactory</code> which provides many utility methods such as
 						<code class="code">ValueFactory.valueOf(Object)</code> for creating a
 						<code class="code">Value</code> from a naked Java object. The reverse conversion from a value to a naked Java object may be be performed by
 						<code class="code">Value.asObject()</code> with
 						methods in derived value classes providing stronger type returns.
 					</p>
 </div>
 <div class="section" title="Polymorphic Integers">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="PivotIntegers"></a>Polymorphic Integers</h4>
 </div>
 </div>
 </div>
 <p>The
 						<code class="code">IntegerValue</code> interface has a family of IntIntegerValueImpl, LongIntegerValueImpl and BigIntegerValueImpl realizations that use Java types internally but support numeric growth where necessary without imposing the overheads of BigInteger on the vast majority of mundane usages. The wrapping of
 						<code class="code">int</code> in
 						<code class="code">IntegerIntValueImpl</code> is very comparable to the wrapping of
 						<code class="code">int</code> in
 						<code class="code">java.lang.Integer</code> so there is little performance or representation cost.
 					</p>
 <p>This enables the Pivot evaluator to handle unlimited integers as specified by the OMG OCL specification.</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 							Prior to the Juno release the handling of greater than 32 bit integers in the classic evaluator was suspect. The Juno release enhances support to allow for 64 bit integers but makes no provision for greater than 64 bit evaluations.</p>
 </blockquote>
 </div>
 <p></p>
 </div>
 <div class="section" title="Polymorphic Collections">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="PivotCollections"></a>Polymorphic Collections</h4>
 </div>
 </div>
 </div>
 <p>The
 						<code class="code">CollectionValue</code> interface has multiple implementations for Bag, OrderedSet, Sequence and Set with implementations that observe OMG OCL semantics.
 					</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 							The classic implementation uses Java collections directly, which unfortunately means that the Java semantics for equality is used. Consequently the classic evaluator incorrectly evaluates
 							<code class="code">Set{1,1.0}-&gt;size()</code> as
 							<code class="code">2</code>.
 						</p>
 </blockquote>
 </div>
 <p></p>
 <p>Using a distinct hierarchy of collection classes opens up opportunities for smart operation, such as in-place update for collections that are rendered redundant by a calculation.</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 							The classic implementation creates a new collection at every opportunity.</p>
 </blockquote>
 </div>
 <p></p>
 </div>
 <div class="section" title="Polymorphic Objects">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="PivotObjects"></a>Polymorphic Objects</h4>
 </div>
 </div>
 </div>
 <p>The
 						<code class="code">ObjectValue</code> interface has an implementation for EObject and further implementations for more specialized objects such as types.
 					</p>
 <p>The Pivot evaluator can be used on alternate data models by providing an alternate
 						<code class="code">ObjectValue</code> to wrap
 						an alternative form of data object.
 					</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 							The classic implementation uses EObject directly, which makes use of non-EObject data models rather hard.</p>
 </blockquote>
 </div>
 <p></p>
 </div>
 </div>
 <div class="section" title="The Pivot Evaluator Type System">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ThePivotEvaluatorTypeSystem"></a>The Pivot Evaluator Type System</h3>
 </div>
 </div>
 </div>
 <p>The Pivot Evaluator uses a very lightweight type system so that alternate implementations can be used.</p>
 <p>For compiled evaluation, a dispatch-table based implementation is used.</p>
 <p>For OCL compilation, a UML-aligned representation of the combined UML, OCL, library and user type systems is used.</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						The classic implementation uses either UML or Ecore meta-models directly, with Ecore as the meta-meta-model. Consequently there was no support for oclType(). Reflection was available in the non-OMF Ecore domain, so
 						the meta-meta-class is &ldquo;EClass&rdquo; rather than &ldquo;Class&rdquo;.</p>
 </blockquote>
 </div>
 <p></p>
 </div>
 <div class="section" title="The Pivot Evaluator Implementation System">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ThePivotEvaluatorImplementationSystem"></a>The Pivot Evaluator Implementation System</h3>
 </div>
 </div>
 </div>
 <p>The Pivot evaluator may be used in an interpreted form similar to the classic evaluator. In this form the evaluator performs a tree-walk over the Abstract Syntax Tree of the OCL expression. Languages that extend OCL may extend this tree-walk by implementing the relevant visitor evaluations for additional AST nodes.</p>
 <p>A partially optimized code generator is available for the Pivot evaluator for which the code generator walks the AST at compile-time. The code generator may be extended to support code generation for languages that extend OCL. See the QVTi code generator in the QVTd project as an example.</p>
 </div>
 <div class="section" title="Polymorphic Implementations">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="PolymorphicImplementations"></a>Polymorphic Implementations</h3>
 </div>
 </div>
 </div>
 <p>The OCL Standard Library comprises packages of classes with one class per library feature, each class implementing the polymorphic implementation interface.</p>
 <p>Provision of additional library function therefore requires</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>provision of the Java class for the library feature</p>
 </li>
 <li class="listitem">
 <p>declaration of the library feature </p>
 </li>
 </ul>
 </div>
 <p>Library features (properties, operations and iterations) are declared in a Standard Library model that identifies the invocation signature and binds it to a Java implementation.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6200-library-declarations.png"></div>
 <p>

 </p>
 <p>The extract from
 					<code class="code">/org.eclipse.ocl.library/model/OCL-2.5.oclstdlib</code> shows the declaration of the
 					<code class="code">Collection</code> type as a templated type with a
 					<code class="code">T</code> parameter. The
 					<code class="code">Collection</code> type conformsTo (extends/inherits/generalizes) the
 					<code class="code">OclAny</code> type and is an instance of the
 					<code class="code">CollectionType</code> meta-type.
 				</p>
 <p>The
 					<code class="code">asSet</code> operation takes no arguments and returns a
 					<code class="code">Set(T)</code>, a set of the collection template type. The declaration is bound to
 					<code class="code">org.eclipse.ocl.library.collection.CollectionAsSetOperation</code> which is the Java class name of the implementation.
 				</p>
 <p>The
 					<code class="code">exists</code> iteration has two overloads, taking one or two iterators of the collection template type. The iteration body is a lambda expression operating on a collection template element with no additional arguments to return a Boolean value. The iteration also returns a Boolean value. The same Java implementation class is used for both one and two argument forms.
 				</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						The corresponding implementations in the classic evaluator were mostly inlined within the
 						<code class="code">EvaluationVisitorImpl.visitOperationCallExp</code> method and so were difficult to extend.
 					</p>
 <p>The corresponding declarations in the classic evaluator were partially modeled in
 						<span class="bold"><strong>oclstdlib.ecore</strong></span> or
 						<span class="bold"><strong>oclstdlib.uml</strong></span>, although in practice an equivalent manually code model initialization is used. The type declarations used by the parser and analyzer are independently coded and do not support iterations as modeled concepts.
 					</p>
 </blockquote>
 </div>
 <p></p>
 </div>
 </div>
 <div class="section" title="Pivot Standalone Configuration">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="PivotStandalone"></a>Pivot Standalone Configuration</h2>
 </div>
 </div>
 </div>
 <p>If you use Eclipse OCL within Eclipse you should find that the appropriate registrations are provided for you automatically by the plugin registration mechanisms.</p>
 <p>However if you use Eclipse OCL outside Eclipse, for instance in JUnit tests, you must provide the corresponding registrations in your code.</p>
 <div class="literallayout">
 <p>
 <code class="code">org.eclipse.ocl.pivot.OCL.initialize(resourceSet);<br>
 org.eclipse.ocl.pivot.uml.UML2AS.initialize(resourceSet);<br>
 org.eclipse.ocl.pivot.model.OCLstdlib.install();<br>
 org.eclipse.ocl.pivot.delegate.OCLDelegateDomain.initialize(resourceSet);<br>
 org.eclipse.ocl.xtext.completeocl.CompleteOCLStandaloneSetup.doSetup();<br>
 org.eclipse.ocl.xtext.oclinecore.OCLinEcoreStandaloneSetup.doSetup();<br>
 org.eclipse.ocl.xtext.oclstdlib.OCLstdlibStandaloneSetup.doSetup();<br>
 org.eclipse.ocl.domain.utilities.StandaloneProjectMap.getAdapter(resourceSet);<br>

 <br>

 </code>
 </p>
 </div>
 <p></p>
 <p>These are elaborated on below.</p>
 <div class="section" title="Models">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Models2"></a>Models</h3>
 </div>
 </div>
 </div>
 <p>For the Pivot metamodel, the required registrations should be provided by invoking

 					<code class="code">org.eclipse.ocl.pivot.OCL.initialize(ResourceSet)</code>. This initialization ensures that *.ecore is understood.
 				</p>
 <p>If *.uml support is also required, invoke

 					<code class="code">org.eclipse.ocl.pivot.uml.UML2AS.initialize(ResourceSet)</code> as well.
 					This initialization ensures that *.uml is understood and that standard pathmap: locations are resolvable. It also invokes
 					<code class="code">org.eclipse.uml2.uml.resources.util.UMLResourcesUtil.init(ResourceSet)</code> to ensure that all Eclipse and OMG UML namespaces and extensions are registered.
 				</p>
 </div>
 <div class="section" title="OCL Standard Library">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLStandardLibrary"></a>OCL Standard Library</h3>
 </div>
 </div>
 </div>
 <p>If you want to use the default OCL Standard Library you should invoke
 					<code class="code">org.eclipse.ocl.pivot.model.OCLstdlib.install()</code> which installs a compiled shareable form of
 					<code class="code">/org.eclipse.ocl.library/model/OCL-2.5.oclstdlib</code>.
 				</p>
 <p>If you want to use an alternate library examine the code for the standard installation above, and if you want to compile your library examine the
 					<code class="code">/org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/GenerateOCLstdlibModel.mwe2</code> launcher for the

 					<code class="code">/org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/acceleo/generateOCLstdlib.mtl</code> Acceleo template.
 				</p>
 <p>Note that the library is extensible and importable so you may import your own library that in turn imports the standard library.</p>
 <p>If you neglect to install an OCL Standard Library, you get the error &ldquo;No OCL Standard Library content available&rdquo;. If you provide a custom library that fails to meet the miinimal requirements of defining the basic library types (e.g. Boolean, Set, Tuple) and methods (e.g. OclAny::&ldquo;=&rdquo;) you get an error such as &ldquo;No 'Boolean' type in the OCL Standard Library&rdquo;.</p>
 </div>
 <div class="section" title="Pivot Delegates">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="PivotDelegates"></a>Pivot Delegates</h3>
 </div>
 </div>
 </div>
 <p>If you have textual OCL embedded within Ecore models you need to register the EMF delegates so that EMF gets, calls or validates dispatch the embedded OCL to the OCL delegates. The required registrations may be provided by
 					<code class="code">OCLDelegateDomain.initialize(ResourceSet)</code> from the
 					<code class="code">org.eclipse.ocl.pivot.delegate</code> package.
 				</p>
 <p>This may be invoked with a null argument to install the registrations in the global EPackage.Registry rather than a specified local registry.</p>
 <p>If you neglect to register delegates before generated EMF classes are initialized, you may get an NPE or an error of the form "An exception occurred while delegating evaluation of the ..."</p>
 </div>
 <div class="section" title="Xtext Parsers">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="XtextParsers"></a>Xtext Parsers</h3>
 </div>
 </div>
 </div>
 <p>If you want to be able to convert any textual form of OCL to its internal pivot form you need to initialize the relevant parser.</p>
 <p>*.ocl Complete OCL documents are initialized by
 					<code class="code">CompleteOCLStandaloneSetup.doSetup()</code>.
 				</p>
 <p>*.oclinecore metamodels are initialized by
 					<code class="code">OCLinEcoreStandaloneSetup.doSetup()</code>

 </p>
 <p>*.oclstdlib OCL Standard Library definitions are initialized by
 					<code class="code">OCLstdlibStandaloneSetup.doSetup()</code>.
 				</p>
 <p>*.ecore, *.essentialocl, *.uml files or general use of the query API is initialized by
 					<code class="code">EssentialOCLStandaloneSetup.doSetup()</code>.
 				</p>
 <p>Each of the above ensures that everything that it requires is installed. The various set ups can be found in one of the following packages:</p>
 <div class="literallayout">
 <p>
 <code class="code">org.eclipse.ocl.xtext.completeocl.<br>
 org.eclipse.ocl.xtext.essentialocl.<br>
 org.eclipse.ocl.xtext.oclinecore.<br>
 org.eclipse.ocl.xtext.oclstdlib.<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 <div class="section" title="platform:/plugin and platform:/resource URIs">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="platformpluginandplatformresourceURIs"></a>platform:/plugin and platform:/resource URIs</h3>
 </div>
 </div>
 </div>
 <p>If you want to be able to use
 					<code class="code">platform:/plugin/...</code> or
 					<code class="code">platform:/resource/...</code> URIs in a standalone configuration you need to configure the EMF package and URI map registries appropriately. This is a costly activity that involves scanning the classpath and exploiting the content of any plugin.xml and MANIFEST.MF files that are found.
 				</p>
 <div class="literallayout">
 <p>
 <code class="code">org.eclipse.ocl.domain.utilities.StandaloneProjectMap.getAdapter(resourceSet);<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>creates a
 					<code class="code">StandaloneProjectMap</code> to cache all the scan results, initializes the ResourceSet and installs itself as an adapter on the ResourceSet so that it can be retrieved again if needed. Users are strongly recommended to ensure that a single
 					<code class="code">StandaloneProjectMap</code> is shared by all clients and so avoid incurring the classpath scan cost more than once.
 				</p>
 <p>(The
 					<code class="code">StandaloneProjectMap</code> has no OCL-specific functionality; it just cures a major problem in the standalone usage of EMF.)
 				</p>
 </div>
 <div class="section" title="Classpath">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Classpath"></a>Classpath</h3>
 </div>
 </div>
 </div>
 <p>If your standalone environment supports OSGI bundles, as will be the case when you use Eclipse to launch a JUnit test or a transformation, the required plugin dependencies are easily configured in the MANIFEST.MF using JDT quick fixes, or the Manifest editor.</p>
 <p>For a totally standalone Java launch, you must identify the exact spelling of each JAR that you require and identify it on your Java classpath. The Eclipse JARs may be found in the plugins folder adjacent to your eclipse.exe. So you may need
 					<code class="code">org.eclipse.ocl.common_1.0.0.v20120516-1543.jar</code> amongst many others. The required JARs can be recursively determined by looking at the Class Not Found Exceptions from the Java launch and locating the plugin with a similar name prefix. This is very tedious and has to be repeated each time you upgrade, so don&rsquo;t do it. Use OSGI. However if you must, the following dependency trees may provide some clues.
 				</p>
 <p>The dependency tree for the basic parsing and evaluation is:</p>
 <div class="literallayout">
 <p>
 <code class="code">org.eclipse.ocl.common<br>
 &nbsp;&nbsp;org.eclipse.ocl.pivot<br>
 &nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.library<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.pivot.internal<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.xtext.base<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.xtext.essentialocl<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.xtext.completeocl<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.xtext.oclinecore<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.xtext.oclstdlib<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>Additionally the UI requires</p>
 <div class="literallayout">
 <p>
 <code class="code">org.eclipse.ocl.common.ui<br>
 &nbsp;&nbsp;org.eclipse.ocl.examples.markup<br>
 &nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.examples.markup.ui<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.xtext.essentialocl.ui<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.xtext.completeocl.ui<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.xtext.oclinecore.ui<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.xtext.oclstdlib.ui<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.examples.xtext.console<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.ocl.pivot.ui<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>You may also need the Xtext, EMF, MWE, Orbit plugins and their dependencies</p>
 <div class="literallayout">
 <p>
 <code class="code">com.google.guava<br>
 com.google.inject<br>
 org.apache.log4j<br>
 org.eclipse.emf.common<br>
 &nbsp;&nbsp;org.eclipse.emf.ecore<br>
 &nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.emf.codegen<br>
 &nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.emf.ecore.xmi<br>
 org.eclipse.xtext<br>
 &nbsp;&nbsp;org.eclipse.xtext.common.types<br>
 &nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.xtext.common.types.ui<br>
 &nbsp;&nbsp;org.eclipse.xtext.ui<br>
 &nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.xtext.ui.shared<br>
 &nbsp;&nbsp;org.eclipse.xtext.util<br>

 </code>
 </p>
 </div>
 <p></p>
 </div>
 </div>
 <div class="section" title="Pivot Thread Safety">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="PivotThreadSafety"></a>Pivot Thread Safety</h2>
 </div>
 </div>
 </div>
 <p>OCL is declarative and side effect free and so particularly suitable for execution on multiple threads, provided all shared context is maintained in ways that avoid inter-thread conflicts.</p>
 <p>The classic Ecore-based OCL evaluation makes no attempt to guarantee thread safety and some of the more recent functionality involving EMF delegate caches is very suspect for multiple thread usage. So if you want thread safety use the Pivot-based evaluation.</p>
 <p>The thread safety of interpreted Pivot evaluation is similarly suspect, however the much faster code generated evaluation is designed for thread safety.</p>
 <div class="section" title="Code Generated Evaluation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="CodeGeneratedEvaluation"></a>Code Generated Evaluation</h3>
 </div>
 </div>
 </div>
 <p>The code-generated evaluator is intended to be thread-safe; all shared objects update their caches within relatively fine-grained synchronized regions. However there are a number of class static variables that are not synchronized and might therefore experience at best a redundant multiple initialization and at worst an assumed uniqueness violation. Thread safe code must therefore invoke:</p>
 <div class="literallayout">
 <p>
 <code class="code">	org.eclipse.ocl.domain.values.util.ValuesUtil.initAllStatics()<br>

 </code>
 </p>
 </div>
 <p></p>
 <p>to ensure eager initialization of unsynchronized class variables. This routine is itself synchronized and so may be safely invoked on all threads, if it is not practical to invoke it solely from just a startup thread.</p>
 <p>It is not permissible to modify any part of any OCL object, array or collection.</p>
 <p>Application code should not assume that the getter for a protected final field is invoked internally and so should not attempt to modify behavior by overriding it.</p>
 <div class="section" title="Design Notes">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="DesignNotes"></a>Design Notes</h4>
 </div>
 </div>
 </div>
 <p>Loose miscellaneous static fields are initialized by ValuesUtil.initAllStatics().</p>
 <p>Most non-static fields are @NonNull and final eliminating thread hazards. However lazy caches cannot be avoided and these require manual review. Caches shared across OCl invocations use Weak references to avoid leakage.</p>
 <p>ElementIds are unique and shared across OCL evaluations and so IdManager maintains a hierarchy of synchronized caches for distinct forms of ElementId.
 						Some ElementIds such as TemplateParameterId are subject to two-phase construction (constructor followed by install). It is assumed that a half-constructed ElementId will not be made visible to other threads.</p>
 <p>Values are optionally shared and so valuesUtil has a few loose statics for simple values such as FALSE, and a synchronized cache for integers in the range -256 to 1024.</p>
 <p>EvaluatorIterationManagers do not currently permit forking of iterations to multiple threads and may malfunction if application code does so.</p>
 </div>
 </div>
 <div class="section" title="Interpreted Evaluation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="InterpretedEvaluation"></a>Interpreted Evaluation</h3>
 </div>
 </div>
 </div>
 <p>This is not considered thread-safe. Superficial consideration suggests that the EMF delegate dispatching in particular needs careful attention.</p>
 </div>
 <div class="section" title="OCL Analysis">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLAnalysis"></a>OCL Analysis</h3>
 </div>
 </div>
 </div>
 <p>The Xtext-based functionality is only thread-safe in so far as Xtext imposes strict main/worker thread disciplines. It is very unlikely that activating additional worker threads will give satisfactory results.</p>
 </div>
 </div>
 <div class="section" title="Parsing Constraints and Queries">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="PivotParsingConstraints"></a>Parsing Constraints and Queries</h2>
 </div>
 </div>
 </div>
 <p>This section may be contrasted with the corresponding
 				<a class="link" href="#ParsingConstraints" title="Parsing Constraints and Queries">Parsing Constraints and Queries</a> for the Ecore binding to see examples of the changes needed to migrate from the Ecore binding to the Pivot binding.
 			</p>
 <p>The OCL parser provides two APIs for parsing constraint and query expressions using the
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/pivot/utilities/OCL.html" target="_new">
 					<code class="code">OCL</code>
 				</a> Facade.
 			</p>
 <div class="section" title="The OCL Facade">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheOCLFacade2"></a>The OCL Facade</h3>
 </div>
 </div>
 </div>
 <p>The
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/pivot/utilities/OCL.html" target="_new">
 						<code class="code">OCL</code>
 					</a> class provides both a Facade and a Handle for the various objects that support different aspects of OCL parsing and evaluation.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6310-environment.png"></div>
 <p>

 </p>
 <p>The
 					<code class="code">OCL</code> class is a simple type.
 				</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						There is no need for the many template parameters that parameterize the equivalent OCL class for the Ecore/UML bindings.</p>
 </blockquote>
 </div>
 <p></p>
 <p>Behind the scenes,
 					<code class="code">OCL</code> instances share an
 					<code class="code">EnvironmentFactory</code> that creates and owns the primary support objects and provides an API to create these and other important artefacts.
 				</p>
 <p>The
 					<code class="code">ProjectManager</code> supports the discovery of metamodels to resolve URI references.
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">OCL.NO_PROJECTS</code> is a very lightweight
 							<code class="code">ProjectManager</code> supporting access only to those models known to the external
 							<code class="code">ResourceSet</code>.
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">OCL.CLASS_PATH</code> is a heavyweight
 							<code class="code">ProjectManager</code> supporting access to models registered with plugins on the Java classpath.
 						</p>
 </li>
 </ul>
 </div>
 <p>The external
 					<code class="code">ResourceSet</code> is a potentially user-supplied
 					<code class="code">ResourceSet</code> to manage the external metamodels such as Ecore or UML models or Xtext Concrete Syntax models.
 				</p>
 <p>The external metamodels are converted to the normalized Pivot representation under control of the
 					<code class="code">MetamodelManager</code> which maintains the normalized representation in an Abstract Syntax as
 					<code class="code">ResourceSet</code>.
 				</p>
 <p>A merged view of the normalized metamodels is provided by the
 					<code class="code">CompleteModel</code>  under control of the
 					<code class="code">CompleteEnvironment</code> that also supervises a
 					<code class="code">StandardLibrary</code>,
 					<code class="code">TupleManager</code> and
 					<code class="code">LambdaManager</code> for more specialized aspects of the merge. The
 					<code class="code">CompleteEnvironment</code> API supports synthesis of Collection and Map types.
 				</p>
 <p>Access to the normalized representations from diverse contexts, in particular from generated Java code, requires an ability to discover the merged representation of e.g. the
 					<span class="bold"><strong>Boolean</strong></span> type from the minimal concept of a
 					<span class="bold"><strong>Boolean</strong></span> type-id. The
 					<code class="code">IdResolver</code> performs the id-to-object conversion.
 				</p>
 <p>When Pivot models are derived from Xtext source text, a Concrete Syntax representation is converted to the normalized Abstract Syntax. The
 					<code class="code">CS2ASMapping</code> tracks the equivalences in this conversion so that tooling can reverse the navigation to discover appropriate text to highlight in a source editor for an underlying model element.
 				</p>
 <p>The
 					<code class="code">OCL</code> handle may also reference a
 					<code class="code">ModelManager</code>. This is used to identify objects during evaluation of operations such as
 					<code class="code">allInstnaces()</code>.
 				</p>
 </div>
 <div class="section" title="OCL Handles">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OCLHandles"></a>OCL Handles</h3>
 </div>
 </div>
 </div>
 <p>The static factory methods of the
 					<code class="code">OCL</code> class are used to create new instances. These are suitable for suitable for parsing OCL constraints
 					on any Ecore or UML model and evaluating them on instances of the model.
 				</p>
 <p>If you already have models loaded in a
 					<code class="code">ResourceSet</code>, you may activate OCL functionality by creating a new
 					<code class="code">OCL</code> instance specifying that OCL should exploit that ResourceSet.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6310-creating-external.png"></div>
 <p>


 <a class="ulink" href="../references/6310-creating-external.txt" target="_new">[Text for cut and paste]</a>

 </p>
 <p>Alternatively you may leave the
 					<code class="code">OCL</code> instance to create the
 					<code class="code">ResourceSet</code>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6310-creating-internal.png"></div>
 <p>


 <a class="ulink" href="../references/6310-creating-internal.txt" target="_new">[Text for cut and paste]</a>

 </p>
 <p>It is good practice to invoke
 					<code class="code">dispose()</code> explicitly to release all
 					OCL-related Resource references promptly rather than rely on garbage collection.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6310-dispose.png"></div>
 <p>


 <a class="ulink" href="../references/6310-dispose.txt" target="_new">[Text for cut and paste]</a>

 </p>
 <p>When repeated parsing and evaluation occurs on a model, it is very beneficial to re-use rather than
 					re-create the underyling OCL support objects. This is easily achieved in simple scenarios by re-using the

 					<code class="code">OCL</code> instance directly. In more complex scenarios the handle behavior of an
 					<code class="code">OCL</code> instance can be exploited
 					to create multiple handles for diverse usages each of which is disposed when complete. The dispose of the
 					underlying OCL support occurs when the final handle disposes.
 				</p>
 </div>
 <div class="section" title="Class Context">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ClassContext"></a>Class Context</h3>
 </div>
 </div>
 </div>
 <p>Parsing an OCL expression requires a classifier to define the type of
 					<code class="code">self</code>. This is passed to

 					<code class="code">createInvariant()</code>, which enforces a Boolean result type, or to
 					<code class="code">createQuery()</code>, which allows any result type.
 				</p>
 <p>The result of parsing a query expression or a constraint is an

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/pivot/ExpressionInOCL.html" target="_new">
 						<code class="code">ExpressionInOCL</code>
 					</a>,
 					an instance of the
 					<a class="link" href="#AbstractSyntax" title="OCL Abstract Syntax Model">Abstract Syntax Model</a>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6310-context.png"></div>
 <p>


 <a class="ulink" href="../references/6310-context.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 <div class="section" title="Operation and Property Contexts">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="OperationandPropertyContexts"></a>Operation and Property Contexts</h3>
 </div>
 </div>
 </div>
 <p>In the case of constraints on operations or properties, the context consists
 					of two elements: the constrained operation/property and a classifier that
 					defines the type of
 					<code class="code">self</code> while parsing the OCL. The classifier is deduced as the
 					container of the operation or property. These can be constrained as follows:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6310-define.png"></div>
 <p>


 <a class="ulink" href="../references/6310-define.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 <div class="section" title="Errors">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Errors"></a>Errors</h3>
 </div>
 </div>
 </div>
 <p>The preceding examples are simplified by the assumption that there will be no parsing errors. In practice
 					<code class="code">ParserException</code>s should be caught and handled in an appropriate way by the application.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6310-errors.png"></div>
 <p>


 <a class="ulink" href="../references/6310-errors.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 <div class="section" title="The OCL Helper">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheOCLHelper2"></a>The OCL Helper</h3>
 </div>
 </div>
 </div>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						The Ecore/UML bindings for OCL provide an OCLHelper class to assist in creating queries. A similar
 						class is available with the Pivot binding for compatibility although it is largely redundant since
 						the
 						<code class="code">OCL</code> class class be used directly. An
 						<code class="code">OCLHelper</code> will give a small performance benefit
 						for multiple parses but not as much as direct use of an underlying
 						<code class="code">ParserContext</code> or a structuring
 						multiple queries in a Complete OCL document.
 					</p>
 <p>From an OCL instance, we can create a helper object with which to parse constraints
 						and additional operation/attribute definitions.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6310-oclhelper.png"></div>
 <p>

 </p>
 <p>The
 						<code class="code">OCLHelper</code> is primarily designed for parsing
 						constraints and query expressions embedded in models, providing the following
 						API for that purpose:
 					</p>
 <p>*
 						<code class="code">createQuery()</code>: parses a query expression
 					</p>
 <p>*
 						<code class="code">createConstraint()</code>: parses a constraint of a given
 						<code class="code">ConstraintKind</code>

 </p>
 <p>*
 						<code class="code">createInvariant()</code>: convenience for invariant constraints
 					</p>
 <p>*
 						<code class="code">createPrecondition()</code>: convenience for pre-condition constraints
 					</p>
 <p>*
 						<code class="code">createPostcondition()</code>: convenience for post-condition constraints
 					</p>
 <p>*
 						<code class="code">createBodyCondition()</code>: convenience for body conditions
 					</p>
 <p>*
 						<code class="code">createDerivedValueExpression()</code>: convenience for attribute derived values
 					</p>
 <p>Different kinds of constraints require different context environments.  The

 						<code class="code">setContext()</code>,
 						<code class="code">setOperationContext()</code>,
 						and
 						<code class="code">setAttributeContext()</code> methods create the appropriate
 						nested
 						<code class="code">Environment</code> s in the host
 						<code class="code">OCL</code>
 						instance&rsquo;s root environment.
 					</p>
 <p>The Ecore/UML bindings variously produce a Constraint or OCLExpression result. A Constraint has too much context and an OCLExpression too little. An ExpressionInOCL produced by the Pivot binding is just right.</p>
 </blockquote>
 </div>
 <p></p>
 </div>
 </div>
 <div class="section" title="Evaluating Constraints and Queries">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="PivotEvaluatingConstraints"></a>Evaluating Constraints and Queries</h2>
 </div>
 </div>
 </div>
 <p>In
 				<a class="link" href="#PivotParsingConstraints" title="Parsing Constraints and Queries">Parsing Constraints</a>, we saw how to use
 				the
 				<code class="code">OCL</code> Facade to parse a textual OCL constraint or query expressions to give its

 				<code class="code">ExpressionInOCL</code> compiled representation. Parsing constraints is interesting,
 				but evaluating them using the

 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/pivot/utilities/Query.html" target="_new">
 					<code class="code">Query</code>
 				</a>
 				API is much more useful.
 			</p>
 <div class="section" title="The OCL Query">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheOCLQuery2"></a>The OCL Query</h3>
 </div>
 </div>
 </div>
 <p>The

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/pivot/utilities/Query.html" target="_new">
 						<code class="code">Query</code>
 					</a>
 					class wraps the minimal
 					<code class="code">ExpressionInOCL</code> parse result to provide evaluation capabilities.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6315-query.png"></div>
 <p>

 </p>
 <p>The
 					<code class="code">Query</code> encapsulates an

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/pivot/evaluation/EvaluationEnvironment.html" target="_new">
 						<code class="code">EvaluationEnvironment</code>
 					</a>
 					providing the run-time values of context variables to the OCL interpreter.  These
 					context variables are set and retrieved using the following methods:
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>

 <code class="code">add(TypedElement, Object)</code>: adds a TypedElement-to-value binding
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">replace(TypedElement, Object)</code>:  replaces an existing binding
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">remove(TypedElement)</code>:  removes a binding
 						</p>
 </li>
 <li class="listitem">
 <p>

 <code class="code">getValueOf(TypedElement)</code>: obtains a binding value
 						</p>
 </li>
 </ul>
 </div>
 <p>.bq
 					The Ecore/UML binding of Eclipse OCL used String rather than TypedElement to support name-to-value bindings.
 					The use of TypedElement rather than String avoids whereby the same name refers to multiple Variables depending on context.
 					.p </p>
 <p>The context variables of primary interest are
 					<code class="code">self</code>
 					and, in operation constraints, the variables corresponding to its parameters.
 				</p>
 <p>An important consideration for OCL evaluation is the

 					<code class="code">allInstances()</code> operation, which obtains the entire
 					extent of a classifier. For data types, this is a simple problem:  the extent
 					of an
 					<code class="code">Enumeration</code> is well defined and the extents of
 					other kinds of
 					<code class="code">DataType</code>s are undefined.  For

 					<code class="code">Class</code> extents, the
 					<code class="code">OCL</code> handle references a
 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/pivot/evaluation/ModelManager.html" target="_new">
 						<code class="code">ModelManager</code>
 					</a>
 					that provides access to the user&rsquo;s models. The default

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/pivot/internal/evaluation/PivotModelManager.html" target="_new">
 						<code class="code">PivotModelManager</code>
 					</a>
 					lazily computes the extent of a class from the EMF
 					<code class="code">ResourceSet</code>
 					containing the context element of the evaluation.
 				</p>
 <p>So, after optionally setting values of context variables (other than

 					<code class="code">self</code>; the
 					<code class="code">Query</code> takes care
 					of this) and an extent map, simply construct a query and use it to evaluate
 					the expression or check the constraint:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6315-check-all.png"></div>
 <p>


 <a class="ulink" href="../references/6315-check-all.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 <div class="section" title="Object representations">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Objectrepresentations"></a>Object representations</h3>
 </div>
 </div>
 </div>
 <p>The example above uses
 					<code class="code">evaluateUnboxed()</code> so that the return value is unboxed and so compatible with the Classic Ecore/UML OCL binding.
 				</p>
 <p>The Pivot binding of OCL supports three distinct Java representations.</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>boxed for internal use</p>
 </li>
 <li class="listitem">
 <p>unboxed for traditional API compatibility</p>
 </li>
 <li class="listitem">
 <p>Ecore for Ecore API compatibility</p>
 </li>
 </ul>
 </div>
 <table id="N15A14">
 <tr>

 <th>OCL</th>
 						<th>Unboxed</th>
 						<th>Ecore</th>
 						<th>Boxed</th>

 </tr>
 <tr>

 <td>Boolean</td>
 						<td>Boolean</td>
 						<td>Boolean</td>
 						<td>Boolean</td>

 </tr>
 <tr>

 <td>String</td>
 						<td>String</td>
 						<td>String</td>
 						<td>String</td>

 </tr>
 <tr>

 <td>Integer</td>
 						<td>Integer/Long/BigDecimal</td>
 						<td>Integer/Long/BigDecimal</td>
 						<td>IntegerValue</td>

 </tr>
 <tr>

 <td>Real</td>
 						<td>Float/Double</td>
 						<td>Float/Double</td>
 						<td>RealValue</td>

 </tr>
 <tr>

 <td>Object</td>
 						<td>EObject</td>
 						<td>EObject</td>
 						<td>EObject</td>

 </tr>
 <tr>

 <td>Type</td>
 						<td>EClassifier</td>
 						<td>EClassifier</td>
 						<td>TypeValue</td>

 </tr>
 <tr>

 <td>null</td>
 						<td>null</td>
 						<td>null</td>
 						<td>null</td>

 </tr>
 <tr>

 <td>invalid</td>
 						<td>InvalidValueException</td>
 						<td>InvalidValueException</td>
 						<td>InvalidValueException</td>

 </tr>
 <tr>

 <td>Collection</td>
 						<td>Collection</td>
 						<td>EList</td>
 						<td>CollectionValue</td>

 </tr>
 <tr>

 <td>Bag</td>
 						<td>Bag</td>
 						<td>EList</td>
 						<td>BagValue</td>

 </tr>
 <tr>

 <td>Sequence</td>
 						<td>List</td>
 						<td>EList</td>
 						<td>SequenceValue</td>

 </tr>
 <tr>

 <td>OrderedSet</td>
 						<td>OrderedSet</td>
 						<td>EList</td>
 						<td>OrderedSetValue</td>

 </tr>
 <tr>

 <td>Set</td>
 						<td>Set</td>
 						<td>EList</td>
 						<td>SetValue</td>

 </tr>
 </table>
 <p>The boxed representation is used wherever the Java semantics of
 					<code class="code">Object.equals(Object)</code> is different
 					to the OCL semantics of
 					<code class="code">OclAny::_'='(OclAny)</code>.
 				</p>
 <p>The unboxed representation is used when a similar representation to the Ecore/UML binding is required.</p>
 <p>The Ecore representation is used for all interchange with Ecore EStructuralFeature values or EOperation
 					arguments and returns.</p>
 </div>
 <div class="section" title="Multiple Evaluations">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="MultipleEvaluations"></a>Multiple Evaluations</h3>
 </div>
 </div>
 </div>
 <p>One of the advantages of the
 					<code class="code">Query</code> API is that a
 					query&rsquo;s evaluation environment can be reused for multiple evaluations, as
 					above.  The extent of any classifier is only computed once.  For convenience,
 					however, in situations where only a single evaluation is required, the

 					<code class="code">OCL</code> class provides shortcuts:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6315-check-one.png"></div>
 <p>


 <a class="ulink" href="../references/6315-check-one.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 <div class="section" title="Succint Evaluations">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="SuccintEvaluations"></a>Succint Evaluations</h3>
 </div>
 </div>
 </div>
 <p>The
 					<code class="code">Query</code> API also provides methods that work on
 					multiple elements.  The first example, above, could be written more succinctly as:
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6315-check-quick.png"></div>
 <p>


 <a class="ulink" href="../references/6315-check-quick.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 </div>
 <div class="section" title="Parsing OCL Documents">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="PivotParsingDocuments"></a>Parsing OCL Documents</h2>
 </div>
 </div>
 </div>
 <p>As we saw in the
 				<a class="link" href="#PivotParsingConstraints" title="Parsing Constraints and Queries">Parsing Constraints and Queries</a> topic, the
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/utilities/OCL.html" target="_new">
 					<code class="code">OCL</code>
 				</a>
 				Facade provides an API for parsing OCL expressions embedded in models as constraints.
 			</p>
 <p>The OCL specification defines a Complete OCL text document with which a UML (or Ecore) metamodel
 				may be completed by providing many complementary constraints and expressions. In this case,
 				the concrete syntax for context declarations indicates the context of
 				constraints, equivalent to their placement in models.</p>
 <p>As an example, consider the following Complete OCL document:</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6320-extlibrary.png"></div>
 <p>


 <a class="ulink" href="../references/6320-extlibrary.ocl" target="_new">[Text for cut and paste]</a>

 </p>
 <div class="section" title="The OCL Input">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TheOCLInput2"></a>The OCL Input</h3>
 </div>
 </div>
 </div>
 <p>The Pivot binding provides a UML-aligned representation and so a Complete OCL document can be parsed to provide a similar Resource to that
 					derived from a UML or Ecore metamodel. A
 					<code class="code">Root</code> contains a
 					<code class="code">Model</code> which contains
 					<code class="code">Package</code>s
 					and
 					<code class="code">Class</code>es. The complementing Resource from the Complete OCL document is independent of the similarly structured
 					complemented Resource of the completed metamodel.
 				</p>
 <p>The Pivot binding uses an Xtext parser with a UML-aligned output. The input text is therefore specified by
 					a URI and loaded by the Xtext parser to create a Concrete Syntax Resource. This may then be converted to the Pivot Abstract Syntax Resource. The Abstract Syntax Resource has a conventional Model, Package, Class, Operation hierarchy in order to provide a coherent composition context for the Constraints.</p>
 <p>The elements of the independent complementing and complemented Resources are merged within
 					<code class="code">CompleteClass</code>es and

 					<code class="code">CompletePackage</code>s of the
 					<code class="code">CompleteModel</code> managed behind the OCL facade.
 				</p>
 <p>There are therefore two
 					<code class="code">Class</code> objects named
 					<span class="bold"><strong>Library</strong></span>, one for each Resource. The objects are distinct in so far as they belong to different resources, which can be separately serialized, and in so far as they may appear distinct to OCL expressions that use reflective access. However they are logically merged and the
 					<code class="code">CompleteEnvironment</code> provides utility methods that allow the multiple objects to be accessed as a merged object.
 				</p>
 <div class="blockquote">
 <blockquote class="blockquote">
 <p>
 						The Ecore binding provided an
 						<code class="code">OCLInput</code> class to supervise the OCL source text, and the result of parsing the document was a
 						<code class="code">List&lt;Constraint&gt;</code>.
 						p.
 					</p>
 </blockquote>
 </div>
 <p>The Complete OCL document is a textual Resource with an associated text tooling. The
 					<code class="code">OCL</code> facade provides
 					an API to load a Resource from a given
 					<code class="code">URI</code>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6320-parsing.png"></div>
 <p>


 <a class="ulink" href="../references/6320-parsing.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 <div class="section" title="Traversing the Constraints">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="TraversingtheConstraints"></a>Traversing the Constraints</h3>
 </div>
 </div>
 </div>
 <p>The parsed resurce can be traversed in the same way as other EMF resources.</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6320-traversing.png"></div>
 <p>


 <a class="ulink" href="../references/6320-traversing.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 <div class="section" title="Accessing the Constraints">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="AccessingtheConstraints2"></a>Accessing the Constraints</h3>
 </div>
 </div>
 </div>
 <p>The contents of the Complete OCL document contribute to a
 					<code class="code">CompleteModel</code> that merges all the contributions.
 					The contributions can therefore be used as if defined in a primary metamodel.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6320-accessing.png"></div>
 <p>


 <a class="ulink" href="../references/6320-accessing.txt" target="_new">[Text for cut and paste]</a>

 </p>
 </div>
 <div class="section" title="Using the Constraints to Validate a Model">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="UsingtheConstraintstoValidateaModel"></a>Using the Constraints to Validate a Model</h3>
 </div>
 </div>
 </div>
 <p>The standard EMF validation makes use of an
 					<code class="code">EValidatorRegistry</code> that maps the URI of an
 					<code class="code">EPackage</code> to the
 					derived
 					<code class="code">EValidator</code> that provides the constraints appilcable to the
 					<code class="code">EPackage</code>. If we want to exploit
 					additional constraints defined in a Complete OCL document, we must extend the underlying
 					<code class="code">EValidator</code>.
 					The
 					<code class="code">ComposedValidator</code> enables multiple
 					<code class="code">EValidator</code> to be composed and to behave as a single

 					<code class="code">EValidator</code>.
 					<code class="code">ComposedEValidator.install()</code> replaces the single
 					<code class="code">EValidator</code> by a composite
 					initially containing just the replaced
 					<code class="code">EValidator</code>. A
 					<code class="code">CompleteOCLEObjectValidator</code> provides the additional validation of the given
 					<code class="code">uri</code> and
 					<code class="code">EPackage</code>.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6320-validating.png"></div>
 <p>


 <a class="ulink" href="../references/6320-validating.txt" target="_new">[Text for cut and paste]</a>

 </p>
 <p>The standard
 					<code class="code">Diagnostician</code> does not directly support validation of a
 					<code class="code">Resource</code>.

 					<code class="code">MyDiagnostician</code> remedies this deficiency and provides a
 					<code class="code">SubstitutionLabelProvider</code>
 					that provides slightly better labels within OCL diagnostics.
 				</p>
 <p>

 </p>
 <div class="mediaobject">
 <img src="images/6320-diagnostician.png"></div>
 <p>


 <a class="ulink" href="../references/6320-diagnostician.txt" target="_new">[Text for cut and paste]</a>

 </p>
 <p>The source for these examples may be found in the org.eclipse.ocl.examples.xtext.tests plugin in model/parsingDocumentsExample.ocl and in src/org/eclipse/ocl/examples/test/xtext/PivotDocumentationExamples.java.</p>
 </div>
 </div>
 <div class="section" title="OCL Relationship to Metamodels">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="PivotMetamodels"></a>OCL Relationship to Metamodels</h2>
 </div>
 </div>
 </div>
 <p>The Pivot-based OCL implementation provides indirect 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" title="Creating Metamodel Bindings">extensibility API</a> that allows
 				additional EMF-based metamodels to be plugged in. The indirection through the UML-aligned Pivot metamodel makes OMG compliance much easier and decouples the implementationm from particular bindings. Support for an alternate concrete metamodel representation is therefore comparatively simple.
 			</p>
 <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/pivot/utilities/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/pivot/utilities/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/examples/pivot/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 Pivot Metamodel Binding">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ThePivotMetamodelBinding"></a>The Pivot Metamodel Binding</h3>
 </div>
 </div>
 </div>
 <p>The preliminary OCL binding for the Pivot metamodel has been provided since the Indigo release by the
 					<code class="code">org.eclipse.ocl.examples.pivot</code> plug-in. This has been promoted to
 					<code class="code">org.eclipse.ocl.pivot</code> in the Mars release.
 				</p>
 <p>The Pivot metamodel prototypes resolutions of the following problems in the OCL 2.4 specification</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>UML-alignment</p>
 </li>
 <li class="listitem">
 <p>OCL Standard Library model</p>
 </li>
 <li class="listitem">
 <p>XMI interchange</p>
 </li>
 <li class="listitem">
 <p>Complete OCL implementability</p>
 </li>
 </ul>
 </div>
 <p>The support for an OCL Standard Library model enables large parts of the OCL specification to be captured by models. This makes the behavior mutable and extensible through definition of alternate or extended library models. (The corresponding Ecore and UML bindings have an Ecore representation of the library but much of its functionality is directly implemented and so immutable.)  </p>
 <p>The Pivot metamodel is auto-generated by a package merge of</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>selected parts of the UML metamodel</p>
 </li>
 <li class="listitem">
 <p>additional OCL packages</p>
 </li>
 <li class="listitem">
 <p>implementation-specific packages</p>
 </li>
 </ul>
 </div>
 <p>The implementation-specific packages provide</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Visitors throughout the entire metamodel (OCL
 							<span class="bold"><strong>and</strong></span> MOF)
 						</p>
 </li>
 <li class="listitem">
 <p>Ecore extensions</p>
 </li>
 </ul>
 </div>
 <p>It is anticipated that the performance advantages of a uniform compliant metamodel, without the complexities of the templates from the
 					<code class="code">org.eclipse.ocl</code> plugin, will outweigh the initial overhead of converting an Ecore or UML metamodel to Pivot form. Once this has been demonstrated, the direct Ecore and UML metamodels will be deprecated.
 				</p>
 <p>The Pivot binding is provided by the

 					<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/org/eclipse/ocl/pivot/internal/utilities/PivotEnvironmentFactory.html" target="_new">
 						<code class="code">PivotEnvironmentFactory</code>
 					</a> class.  For compatibility, as a default, the Pivot environment uses the static
 					<code class="code">EPackage</code> registry to look up package names. This default is deprecated since the domain of
 					<code class="code">allInstances()</code> may be very large when many models are registered.  It should therefore be supplied with an alternative package registry (for example, one local to a
 					<code class="code">ResourceSet</code>) for relevant metamodels. The static registry is then used as a backup for package lookups, but not for
 					<code class="code">allInstances()</code>.  The Pivot environment factory maintains the Pivot models associated with
 				</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>Ecore metamodels in use</p>
 </li>
 <li class="listitem">
 <p>UML metamodels in use</p>
 </li>
 <li class="listitem">
 <p>Library models in use</p>
 </li>
 <li class="listitem">
 <p>Concrete Syntax source models</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="circle">
 <li class="listitem">
 <p>OCLinEcore (rather than Ecore)</p>
 </li>
 <li class="listitem">
 <p>Complete OCL</p>
 </li>
 <li class="listitem">
 <p>OCL Standard Library</p>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
 <p>The Pivot binding for OCL will provide the full capabilities of the UML binding, but at present only the Ecore facilities have been tested. The Pivot binding has the additional ability to support extensions to the library.</p>
 <p>For applications that work exclusively with the Pivot binding for OCL, the
 					<code class="code">org.eclipse.ocl.pivot</code> package defines an
 					<code class="code">OCL</code> class that provides similar facilities to the corresponding Ecore and UML binding equivalents.
 				</p>
 <p>The Pivot metamodel is used by Eclipse OCL for:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>all Xtext editors; editing, parsing, analysis and validation</p>
 </li>
 <li class="listitem">
 <p>the Xtext OCL console; editor and evaluation</p>
 </li>
 <li class="listitem">
 <p>EMF delegates using the http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot URI</p>
 </li>
 <li class="listitem">
 <p>explicit use of the Pivot metamodel from Java</p>
 </li>
 </ul>
 </div>
 <p>The Pivot metamodel is not used by Eclipse OCL for:</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>OCL console editing and evaluation</p>
 </li>
 <li class="listitem">
 <p>EMF delegates using the http://www.eclipse.org/emf/2002/Ecore/OCL/LPG URI</p>
 </li>
 <li class="listitem">
 <p>

 <a class="link" href="#ImpactAnalyzer" title="Incrementally Re-Evaluating OCL Expressions Using the Impact Analyzer">Impact Analyzer</a>.
 						</p>
 </li>
 <li class="listitem">
 <p>explicit use of the Ecore or UML bindings from Java</p>
 </li>
 </ul>
 </div>
 <p>EMF delegates using the http://www.eclipse.org/emf/2002/Ecore/OCL virtual URI are redirected to either http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot or http://www.eclipse.org/emf/2002/Ecore/OCL/LPG by the
 					setting of the &ldquo;Executor targeted by the default OCL delegate&rdquo; preference setting, which defaults to
 					http://www.eclipse.org/emf/2002/Ecore/OCL/LPG for compatibility.</p>
 <p>Note that the Indigo and Juno OCLinEcore editor uses the http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot URI and so uses the
 					<a class="link" href="#PivotEvaluator" title="The Pivot Evaluator">Pivot Evaluator</a>, whereas the Helios OCLinEcore editor used the http://www.eclipse.org/emf/2002/Ecore/OCL URI and so the Ecore evaluator. A file using the http://www.eclipse.org/emf/2002/Ecore/OCL URI will automatically be upgraded to the http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot URI when edited using the Indigo or Juno OCLinEcore editors.
 				</p>
 <p>In Kepler, Luna ans Mars, the OCLinEcore editor preserves any existing delegate URI selection. The new &ldquo;Preferred executor requested for OCL constraints&rdquo; preference determines the URI when no previous setting is available. This defaults to http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot for backwards compatibility.</p>
 </div>
 </div>
 <div class="section" title="Ids">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Pivot-Ids"></a>Ids</h2>
 </div>
 </div>
 </div>
 <p>The ElementId hierarchy provides the simplest base level of metamodel representation. The ElementIds feature</p>
 <div class="itemizedlist">
 <ul class="itemizedlist" type="disc">
 <li class="listitem">
 <p>identity</p>
 </li>
 <li class="listitem">
 <p>uniqueness</p>
 </li>
 <li class="listitem">
 <p>thread-safety</p>
 </li>
 <li class="listitem">
 <p>predictability</p>
 </li>
 <li class="listitem">
 <p>hashcodes</p>
 </li>
 </ul>
 </div>
 <p>Every primary hierachical metamodel object such as a Package, Type, Operation or Property has a globally unique identity established by the package-class-feature path.</p>
 <p>Auxiliary metamodel object such as a TemplateParameter, TuplePart or List-of-Parameter have a locally unique identity supporting fast matching of tuples or single lookup for operation parameters.</p>
 <div class="section" title="Id Equality">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Pivot-Id-Equality"></a>Id Equality</h3>
 </div>
 </div>
 </div>
 <p>ElementIds are unique, whereas metamodel elements are not; there may be many meta-models in many applications all with their own Boolean PrimitiveTypeImpl instances. The equivalence of these elements may be established rapidly since each returns the same TypeId.BOOLEAN singleton from PrimitiveTypeImpl.getTypeId().</p>
 </div>
 <div class="section" title="IdManager">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Pivot-IdManager"></a>IdManager</h3>
 </div>
 </div>
 </div>
 <p>Uniqueness of ElementIds is enforced by the various getXxxId methods of the single IdManager.INSTANCE. These methods are synchronized to ensure thread safety. Child hierarchical objects are similarly mediated by their parent.</p>
 </div>
 <div class="section" title="CollectionTypeId">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Pivot-CollectionTypeId"></a>CollectionTypeId</h3>
 </div>
 </div>
 </div>
 <p>CollectionTypeIds are a degenerate form of specialization/generalization with a single template parameter. The template parameter is declared explicitly in generalizations.</p>
 </div>
 <div class="section" title="TupleTypeId">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Pivot-TupleTypeId"></a>TupleTypeId</h3>
 </div>
 </div>
 </div>
 <p>TupleTypes are self-contained, that is all external template parameter references with the part types are bindings of a specialized tuple type whose generalization replaces those external references by the template parameters of the generalization.</p>
 <p>For instance given a declaration</p>
 <p>Set(A)::op(B)() : Tuple(a:A, b:Bag(B), c:B)</p>
 <p>Tuple(a:A, b:Bag(B), c:B) is the (A,B) specialization of the Tuple(T1,T2)(a:T1,b:Bag(T2),c:T2) generalization.</p>
 </div>
 <div class="section" title="LambdaTypeId">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Pivot-LambdaTypeId"></a>LambdaTypeId</h3>
 </div>
 </div>
 </div>
 <p>LambdaTypes are self-contained in the same way as tuples with specializations of generalizations.</p>
 </div>
 <div class="section" title="ParameterIds">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Pivot-ParameterIds"></a>ParameterIds</h3>
 </div>
 </div>
 </div>
 <p>A ParameterIds identifies an ordered list of typeid suitable for identifying an operation&rsquo;s parameter list by a single object and hashcode.</p>
 <p>A ParameterIds has no knowledge of its parent Operation and so ParameterIds are reused whenever the typeid list arises. Note that collection typeIds are always collectionTypeIds, so there is no need for multiplicities. The residual optional existence is not subject to overloading and is ignored in ParameterIds.</p>
 <p>LambdaTypes reuse ParameterIds to capture the extended type list comprising the typeids of context-type, result-type then parameter-types. </p>
 </div>
 <div class="section" title="TuplePartId">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Pivot-TuplePartId"></a>TuplePartId</h3>
 </div>
 </div>
 </div>
 <p>A TuplePartId identifies a part of a Tuple. It has a name, typeid and index. The index is the part position in the set of parts in a parent tuple alphabetically sorted by name. It provides efficient access to a slot position in a tuple representation.</p>
 <p>A TuplePartId has no knowledge of its parent Tuple and so TuplePartIds are reused whenever the same combination of name, typeid and index arise.</p>
 </div>
 <div class="section" title="TemplateParameterId">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Pivot-TemplateParameterId"></a>TemplateParameterId</h3>
 </div>
 </div>
 </div>
 <p>A TemplateParameterId identifies a template parameter in the ordered list of template parameters in a parent templateable element. It has just an index in the parent list. For debugging purposes a TemplateParameterId has a name such as $0 or $1.</p>
 <p>A TemplateParameterId has no knowledge of its parent templateable element and so only a couple of TemplateParameterIds ever exist. Three are statically defined as TypeId.T_1, T_2, T_3.</p>
 <p>TemplateParameterId has no knowledge of whether it is a type or value parameter. Pragmatically a TemplateParameterId extends a TypeId. (This design decision may need revision.)</p>
 </div>
 <div class="section" title="Code Generation">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="Pivot-Id-CG"></a>Code Generation</h3>
 </div>
 </div>
 </div>
 <p>Since the ElementIds are predictable and unique, code generation can assign them for computation once in static variables so that large parts of the costs of model elememnt location can be performed at compile time. At class load time it is only necessary to construct/share the ElementId object. At run-time the ElementId provides a hashcode to
 					provode rapid lookup.</p>
 </div>
 </div>
 </div>
 <div class="chapter" title="Chapter&nbsp;8.&nbsp;API Reference">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title">
 <a name="APIReference"></a>Chapter&nbsp;8.&nbsp;API Reference</h2>
 </div>
 </div>
 </div>
 <div class="section" title="Javadoc">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Javadoc"></a>Javadoc</h2>
 </div>
 </div>
 </div>
 <p>The Javadoc for Eclipse OCL 6.4.0 (Photon) APIs may be found by following the
 				<a class="ulink" href="http://download.eclipse.org/ocl/javadoc/6.4.0/" target="_new">OCL 6.4.0 API Reference</a> link.
 			</p>
 </div>
 <div class="section" title="Extension points">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="Extensionpoints"></a>Extension points</h2>
 </div>
 </div>
 </div>
 <p>There is one extension point, but it is no longer clear that it has any useful functionality. Please consider it deprecated.</p>
 <p>

 <a class="ulink" href="../references/extension-points/org_eclipse_ocl_environments.html" target="_new">Extension Points Reference</a>.
 			</p>
 </div>
 </div>
 <div class="chapter" title="Chapter&nbsp;9.&nbsp;Building the OCL Project">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title">
 <a name="BuildingtheOCLProject"></a>Chapter&nbsp;9.&nbsp;Building the OCL Project</h2>
 </div>
 </div>
 </div>
 <p>This section contains some details on the way in which the OCL project is built. This should only be of interest to users creating extension of the project.</p>
 <div class="section" title="GenModel GenAnnotations">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title" style="clear: both">
 <a name="GenAnnotations"></a>GenModel GenAnnotations</h2>
 </div>
 </div>
 </div>
 <p>The automated generation of models that form part of the OCL tooling exploits a number of GenAnnotations to influence the auto-generated code.</p>
 <div class="section" title="http://www.eclipse.org/OCL/GenModel GenAnnotation Source">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="httpwww.eclipse.orgOCLGenModelGenAnnotationSource"></a>http://www.eclipse.org/OCL/GenModel GenAnnotation Source</h3>
 </div>
 </div>
 </div>
 <div class="literallayout">
 <p>&lt;genAnnotations&nbsp;source="http://www.eclipse.org/OCL/GenModel"&gt;<br>
 &nbsp;&nbsp;&lt;details&nbsp;key="Use&nbsp;Null&nbsp;Annotations"&nbsp;value="true"/&gt;<br>
 &lt;/genAnnotations&gt;<br>

 </p>
 </div>
 <p>This GenAnnotation is also used by regular OCL code generation</p>
 <div class="section" title="Use Delegates">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="UseDelegates"></a>Use Delegates</h4>
 </div>
 </div>
 </div>
 <p>If the
 						<span class="emphasis"><em>Use Delegates</em></span> key is present and has a
 						<span class="emphasis"><em>true</em></span> value genModel will generate code for OCL expressions that delegates to the run-time interpreter, rather than generating Java code.
 					</p>
 </div>
 <div class="section" title="Use Null Annotations">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="UseNullAnnotations"></a>Use Null Annotations</h4>
 </div>
 </div>
 </div>
 <p>If the
 						<span class="emphasis"><em>Use Null Annotations</em></span> key is present and has a
 						<span class="emphasis"><em>true</em></span> value the generated code will have
 						<span class="emphasis"><em>@NonNull</em></span> and
 						<span class="emphasis"><em>@NonNull</em></span> annotations.
 					</p>
 </div>
 </div>
 <div class="section" title="http://www.eclipse.org/OCL/GenModel/ToString">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="httpwww.eclipse.orgOCLGenModelToString"></a>http://www.eclipse.org/OCL/GenModel/ToString</h3>
 </div>
 </div>
 </div>
 <div class="literallayout">
 <p>&lt;genAnnotations&nbsp;source="http://www.eclipse.org/OCL/GenModel/ToString"&gt;<br>
 &nbsp;&nbsp;&lt;details&nbsp;key="org.eclipse.ocl.examples.codegen.cgmodel.CGElement"<br>
 &nbsp;&nbsp;&nbsp;&nbsp;value="return&nbsp;&amp;lt;%org.eclipse.ocl.examples.codegen.analyzer.CG2StringVisitor%&gt;.toString(this);"/&gt;<br>
 &lt;/genAnnotations&gt;<br>

 </p>
 </div>
 <p>By default EMF generates a toString() method that identifies all attribute values. This cannot be suppressed, only circumvented.</p>
 <p>If the
 					<code class="code">http://www.eclipse.org/OCL/GenModel/ToString</code> GenAnnotation is present the default is changed to use an inherited implementation, which must be specified somewhere.
 				</p>
 <p>Specific implementations of toString may be provided as the values of detail entries whose key is the qualified name of the interface class. Imports may be encoded with the implementation by enclosing the fully qualified name in
 					<code class="code">&lt;%...%&gt;</code>.
 				</p>
 </div>
 <div class="section" title="http://www.eclipse.org/OCL/GenModel/Visitor">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="httpwww.eclipse.orgOCLGenModelVisitor"></a>http://www.eclipse.org/OCL/GenModel/Visitor</h3>
 </div>
 </div>
 </div>
 <div class="literallayout">
 <p>&lt;genAnnotations&nbsp;source="http://www.eclipse.org/OCL/GenModel/Visitor"&gt;<br>
 &nbsp;&nbsp;&lt;details&nbsp;key="Root&nbsp;Visitor&nbsp;Class"&nbsp;value="org.eclipse.ocl.pivot.util.Visitor"/&gt;<br>
 &nbsp;&nbsp;&lt;details&nbsp;key="Derived&nbsp;Visitor&nbsp;Class"&nbsp;value="org.eclipse.ocl.pivot.util.Visitor"/&gt;<br>
 &nbsp;&nbsp;&lt;details&nbsp;key="Visitable&nbsp;Interface"&nbsp;value="org.eclipse.ocl.pivot.util.Visitable"/&gt;<br>
 &nbsp;&nbsp;&lt;details&nbsp;key="Visitable&nbsp;Classes"&nbsp;value="org.eclipse.ocl.pivot.Element"/&gt;<br>
 &lt;/genAnnotations&gt;<br>

 </p>
 </div>
 <p>The accept method for an hierarchical visitor pattern may be woven into the code using the
 					<code class="code">http://www.eclipse.org/OCL/GenModel/Visitor</code> genAnnotation.
 				</p>
 <p>The implementation for class XXXX in the root package is</p>
 <div class="literallayout">
 <p>
 <code class="code">@Nullable&nbsp;R&nbsp;accept(@NonNull&nbsp;RootVisitorClass&lt;R&gt;&nbsp;visitor)&nbsp;{<br>
 	return&nbsp;visitor.visitXXXX(this);<br>
 }&nbsp;<br>

 </code>
 </p>
 </div>
 <p>The implementation for class XXXX in the derived package is</p>
 <div class="literallayout">
 <p>
 <code class="code">@Nullable&nbsp;R&nbsp;accept(@NonNull&nbsp;RootVisitorClass&lt;R&gt;&nbsp;visitor)&nbsp;{<br>
 	return&nbsp;(R)&nbsp;(DerivedVisitorClass&lt;?&gt;)visitor).visitXXXX(this);<br>
 }&nbsp;<br>

 </code>
 </p>
 </div>
 <p>The direct cast to the derived type assumes that the caller has ensured that the visitor in use supports the visitor interfaces for all objects in use.</p>
 <p>The null annotations or omitted unless null annotations have been enabled.</p>
 <div class="section" title="Root Visitor Class">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="RootVisitorClass"></a>Root Visitor Class</h4>
 </div>
 </div>
 </div>
 <p>The fully qualified name of the visitor class must be specified as the value of the
 						<span class="emphasis"><em>Root Visitor Class</em></span> detail. This class defines the argument type of the accept method.
 					</p>
 </div>
 <div class="section" title="Derived Visitor Class">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="DerivedVisitorClass"></a>Derived Visitor Class</h4>
 </div>
 </div>
 </div>
 <p>The fully qualified name of the derived visitor class must be specified as the value of the
 						<span class="emphasis"><em>Derived Visitor Class</em></span> detail. This detail may be omitted for the root package.
 					</p>
 </div>
 <div class="section" title="Visitable Interface">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="VisitableInterface"></a>Visitable Interface</h4>
 </div>
 </div>
 </div>
 <p>The fully qualified name of the visitable interface must be specified as the value of the
 						<span class="emphasis"><em>Visitable Interface</em></span> detail. It&rsquo;s mandatory for the root package.
 					</p>
 </div>
 <div class="section" title="Visitable Classes">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="VisitableClasses"></a>Visitable Classes</h4>
 </div>
 </div>
 </div>
 <p>An @Override annotation is generated for all implementations. This leads to an error where the implementation is not an override. The space-separated fully qualified names of all classes for which the accpe is not an override must be specified as the value of the
 						<span class="emphasis"><em>Visitable Classes</em></span> detail.
 					</p>
 </div>
 <div class="section" title="Implementation Details">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ImplementationDetails"></a>Implementation Details</h4>
 </div>
 </div>
 </div>
 <p>The support for accept is in
 						<code class="code">templates/model/Class/insert.javajetinc</code> where the appropriate code is generated into the implementation file with help from OCLBuildGenModelUtil.
 					</p>
 </div>
 </div>
 <div class="section" title="http://www.eclipse.org/OCL/GenModel/CopyAndPaste">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="httpwww.eclipse.orgOCLGenModelCopyAndPaste"></a>http://www.eclipse.org/OCL/GenModel/CopyAndPaste</h3>
 </div>
 </div>
 </div>
 <div class="literallayout">
 <p>&lt;genAnnotations&nbsp;source="http://www.eclipse.org/OCL/GenModel/CopyAndPaste"&gt;<br>
 &nbsp;&nbsp;&lt;details&nbsp;key="org.eclipse.ocl.xtext.markup.FigureElement"&nbsp;<br>
 &nbsp;&nbsp;&nbsp;value="model/FigureElement.javacopy"/&gt;<br>
 &lt;/genAnnotations&gt;<br>

 </p>
 </div>
 <p>EMF allows custom code to be added to classes using an @Generated NOT comment annotation or no annotation at all. These additions are preserved during regeneration, but may be lost if the file is deleted and regenerated.</p>
 <p>As an alternative, custom contributions may be pasted into class implementation files by specifying a detail entry whose key is the qualified interface name of the class to be customised and whose value is the project-relative name of a file providing text to be copied and pasted.</p>
 <p>The copied text should be tab indented so that it matches the tab indentation of the auto-generated code.</p>
 <p>The copied text may reference types that may need importing by encoding the fully qualified name in
 					<code class="code">&lt;%...%&gt;</code>.
 				</p>
 <p>The customization files are conventionally given a *.copyjava file name and are placed in the model folder alongside the *.genmodel.</p>
 <div class="section" title="Implementation Details">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="ImplementationDetails2"></a>Implementation Details</h4>
 </div>
 </div>
 </div>
 <p>The support for copy and paste is in
 						<code class="code">templates/model/Class/insert.javajetinc</code> where the referenced text is copied into the implementation file with help from OCLBuildGenModelUtil.
 					</p>
 </div>
 </div>
 <div class="section" title="Implementation Details">
 <div class="titlepage">
 <div>
 <div>
 <h3 class="title">
 <a name="ImplementationDetails3"></a>Implementation Details</h3>
 </div>
 </div>
 </div>
 <div class="section" title="org.eclipse.ocl.examples.build">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
 <a name="org.eclipse.ocl.examples.build"></a>
 						<code class="code">org.eclipse.ocl.examples.build</code>

 </h4>
 </div>
 </div>
 </div>
 <p>The
 						<code class="code">org.eclipse.ocl.examples.build</code> plugin hosts the build-time functionality that does not need to bloat the distribution.
 					</p>
 <p>Modified JET templates are in the
 						<code class="code">templates</code> folder which
 						<code class="code">.jetproperties</code> prefixes to the template path. The
 						<code class="code">.project</code> has an
 						<code class="code">org.eclipse.emf.codegen.jet.IJETNature</code> nature and builder so that the custom JET templates are automatically built to the
 						<code class="code">jet-gen</code> source folder. The
 						<code class="code">.project</code> similarly has has an
 						<code class="code">org.eclipse.xtext.ui.shared.xtextNature</code> nature and builder so that the Xtend templates are automatically built to the
 						<code class="code">xtend-gen</code> source folder. Both these generated source folders are excluded from source control, since they are 100% auto-generated and they do not form part of the distribution.
 					</p>
 <p>Custom JET templates are declared by OCLBuildGenModelGeneratorAdapterFactory which creates a OCLBuildGenClassGeneratorAdapter that replaces the normal reference to
 						<code class="code">org.eclipse.emf.codegen.ecore.templates.model.Class</code> by
 						<code class="code">org.eclipse.ocl.examples.build.templates.model.Class</code>.
 					</p>
 <p>The custom build functionality is installed by the
 						<code class="code">GenModelSetup</code> workflow component,
 					</p>
 </div>
 </div>
 </div>
 </div>
 <div class="appendix" title="Appendix&nbsp;A.&nbsp;Glossary">
 <div class="titlepage">
 <div>
 <div>
 <h2 class="title">
 <a name="glossary"></a>Appendix&nbsp;A.&nbsp;Glossary</h2>
 </div>
 </div>
 </div>
 <div class="glosslist">
 <dl>
 <dt>EMF</dt>
 <dd>
 <p>Eclipse Modeling Framework</p>
 </dd>
 <dt>OCL</dt>
 <dd>
 <p>Object Constraint Language</p>
 </dd>
 <dt>OMG</dt>
 <dd>
 <p>Object Management Group</p>
 </dd>
 <dt>QVT</dt>
 <dd>
 <p>Query View Transformation</p>
 </dd>
 <dt>RTF</dt>
 <dd>
 <p>Revision Task Force</p>
 </dd>
 <dt>UML</dt>
 <dd>
 <p>Unified Modeling Language</p>
 </dd>
 </dl>
 </div>
 </div>
 </div>
 </body>
 </html>