• Page
• Discussion
• View source
• History

From Eclipsepedia

You do not have permission to do that, for the following reason:

You can view and copy the source of this page:

In addition to the FAQ below, see also the OCL Developer Guide documentation included in the OCL SDK. __TOC__ == Newbie / General == Questions in this section are directed at those that are new to the MDT OCL component and are interested in finding out how to begin working with it. === What is MDT OCL? === MDT OCL provides a parser and interpreter for OCL constraints and expressions on any [[Eclipse Modeling Framework|EMF]]-based metamodel. By that is meant any metamodel whose meta-metamodel is Ecore, and which (in being a metamodel) provides an EMF importer to create GenModels that generate a Java implementation. So far, the Eclipse Modeling Project has two such metamodels: Ecore and UML (Ecore being its own meta-metamodel). Hence, the OCL component provides an OCL binding for each of these metamodels. OCL can parse constraints in either Ecore or [[MDT-UML2|UML]] models, and can evaluate them on the instances of Java classes generated from these models. In terms of the OMG's modeling "stack", then, we have in the Eclipse Modeling Project {| border="1" |+ align="bottom"|OCL's relation to the OMG modeling stack |- !Modeling Level!!Artifacts!!OCL's Role |- |M3||Ecore||This is the metamodel for the OCL Abstract Syntax Model |- |M2||Ecore, UML||OCL's generic AST model binds to these metamodels |-valign="top" |rowspan="2"| M1 ||*.ecore and *.uml models||rowspan="2"|OCL parses constraints on these models |- |generated Java code |-valign="top" |rowspan="2"| M0 ||instances of generated Java classes||rowspan="2"| OCL evaluates constraints on these objects |- |dynamic EMF objects |} The OCL Abstract Syntax Model is, itself, actually a metamodel sitting at the M2 level. === Does OCL 1.x work with J2SE 1.4? === Because OCL extends EMF's Ecore, OCL's dependencies are the same as those of EMF. <table border="1"><tr><th>OCL</th><th>EMF</th><th>Minimim JVM</th></tr> <tr align="center"> <td>1.0</td> <td>2.2</td> <td>1.4.2</td> </tr> <tr align="center"> <td>1.1</td> <td>2.3</td> <td>1.5</td> </tr> <tr align="center"> <td>1.2</td> <td>2.4</td> <td>1.5</td> </tr> <tr align="center"> <td>1.3</td> <td>2.5</td> <td>1.5</td> </tr> <tr align="center"> <td>3.0</td> <td>?</td> <td>1.5</td> </tr> </table> See also [[EMF/EMF 2.3/JVM Requirements|EMF 2.3 JVM Requirements]]. == OCL Formulation == This section answers common problems in the formulation of OCL expressions that achieve some specific aim. More often than not, these are matters of OCL-the-language, not specific in any way to the MDT implementation. === How do I combine collections of different types? === If you have two or more collections of distinct element types and want to combine them into a single collection, it is not as simple as just unioning them or casting the collections to a common type. In the OCL 2.0 specification, the collection types do not conform to <tt>OclAny</tt>, so they do not have the <tt>oclAsType</tt> operation. Also, the semantics of generic type parameters in collections are undefined, so that it is not clear whether, for example, <tt>Set(T)</tt> has only <tt>union(Set(T))</tt> or also <tt>union(Set(S))</tt> where <tt>S</tt> is any supertype of <tt>T</tt>. Instead, one must do something like: -- given types A, B conforming to S but neither of -- A nor B conforming to the other context S def: union(a : Set(A), b : Set(B)) : Set(S) = let s : Set(S) = Set{} in s->union(a)->union(b) which works because <tt>Set(S)</tt> has an operation <tt>union(Set(S))</tt> that accepts arguments of type <tt>Set(A)</tt> and <tt>Set(B)</tt> because of the rules of conformance of collection types. == OCL Code Generation == === How do I generate code from OCL constraints in UML? === See http://www.eclipse.org/modeling/mdt/uml2/docs/presentations/EclipseCon2008_LongTalk_NewFeaturesOfUML2_files/frame.htm. == OCL Editor == === How do I install an editor for OCL? === An editor for OCL has been developed as part of the M2M/QVT Declarative project. This is being migrated to form part of the MDT/OCL project in the Helios release. It is hoped that the relevant Update Sites will facilitate installation soon. To use this editor now follow the following installation steps. ==== Eclipse 3.5 base ==== You require Eclipse 3.5 or later with EMF (Core), EMF Transaction and EMF Validation. If you already have these you may skip the install Eclipse step. Install the Eclipse 3.5 including the modeling packages. Download e.g. http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/SR1/eclipse-modeling-galileo-SR1-incubation-win32.zip and unzip. ==== Get OCL Editor Project Set File ==== Start Eclipse, Open the CVS Resource Perspective. Create a New Repository Location for Host: dev.eclipse.org Repository Path: /cvsroot/modeling User: anonymous Password: Connection type: pserver Select HEAD/org.eclipse.m2m/org.eclipse.qvt.declarative/plugins/org.eclipse.qvt.declarative.editor.ui/psf and invoke Check Out the psf Folder from the right button menu. ==== Import OCL Editor Project Set ==== In the Project Explorer Select psf/ocl-editor.psf and invoke Import Project Set... specifying anonymous when asked for a CVS account and passwoes. ==== Build OCL Editor Examples ==== Optionally (to make the OCL examples work) Select org.eclipse.qvt.declarative.examples/buildZips.xml and invoke Run As->Ant Build from the right bitton menu. This should successfully create two OCL zips (refresh the project to see them) although it will fail when creating further QVTd zips. ==== Invoke OCL Editor ==== Start a nested Eclipse by selecting some project and invoking Run As->Eclipse Application. To see how the Editor works and get an example configuration Invoke New->Project->Examples->QVT Projects->Royal and Loyal Example Open org.eclipse.qvt.declarative.examples.ocl.royalandloyal/oclsrc/Royal and Loyal/Royal and Loyal.ocl. ==== Create OCL Editor Project ==== An empty prototype project may be created by Invoke New->Project->Examples->QVT Projects->Empty OCL Project The important characteristics of this project are that: The Java build path specifies 'oclsrc' and 'oclbin' folders. The QVTd Model Registry Nature is set enabling the Model Registry Property Page to define models that contribute to the OCL 'package' path. The QVTd OCL Nature is set enabling compliation of the OCL src to an OCL bin AST. [[Category:FAQ]] [[Category:Modeling]] [[Category:MDT]]

Return to MDT/OCL/FAQ.