Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "OCL/FAQ"
m (MDT-OCL-FAQ moved to MDT/OCL/FAQ) |
(Add OCL Formulation section) |
||
Line 4: | Line 4: | ||
== Newbie / General == | == 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? === | === What is MDT OCL? === | ||
Line 68: | Line 70: | ||
See also [[EMF/EMF 2.3/JVM Requirements|EMF 2.3 JVM Requirements]]. | 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. | ||
[[Category:FAQ]] | [[Category:FAQ]] | ||
[[Category:Modeling]] | [[Category:Modeling]] | ||
[[Category:MDT]] | [[Category:MDT]] |
Revision as of 09:46, 30 January 2009
In addition to the FAQ below, see also the OCL Developer Guide documentation included in the OCL SDK.
Contents
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 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 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
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 |
M1 | *.ecore and *.uml models | OCL parses constraints on these models |
generated Java code | ||
M0 | instances of generated Java classes | 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.
OCL | EMF | Minimim JVM |
---|---|---|
1.0 | 2.2 | 1.4.2 |
1.1 | 2.3 | 1.5 |
1.2 | 2.4 | 1.5 |
See also 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 OclAny, so they do not have the oclAsType operation. Also, the semantics of generic type parameters in collections are undefined, so that it is not clear whether, for example, Set(T) has only union(Set(T)) or also union(Set(S)) where S is any supertype of T.
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 Set(S) has an operation union(Set(S)) that accepts arguments of type Set(A) and Set(B) because of the rules of conformance of collection types.