Home » Modeling » OCL » Context environments, package environments , variables, return types, doc
| Context environments, package environments , variables, return types, doc [message #36527] |
Sun, 09 September 2007 00:32  |
 Larry
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
In 1.0, working with EMF, we created an environment for each OCL expression
and put that expression's variables in that environment.
In 1.1, it appears that each context has a hidden sub-environment. Since you
only have access to the OCL instance's root environment, variables are
global to that instance and its root. I think this means that we create an
ocl instance for each context to hold the expression's local variables, and
let the helper create a basically superfluous subenvironment whose only
purpose is to define self. If so, it would be great someday to be able to
assign variables directly to the context environment.
The doc talks about using package level environments to define namespaces. I
can see how to create one, but I can't see how it works. Do I create the
environment, then make it the root of an OCL instance, so that I end up with
an OCL instance for each package? What use does it make of the package info?
The doc also recommends using a single OCL instance. How does that fit with
the above? More generally, would I be better just working directly with
environments and treating OCL and OCLHelper as throwaway convenience classes
instead of trying to use a central OCL?
Great idea to have bindings for specific metamodels, but many of the methods
appear to return the generic supertype instead of the bound subtype so that
I have to cast. E.g.,
org.eclipse.ocl.ecore.VariableExp.getReferredVariable() returns an
org.eclipse.ocl.expressions.Variable rather than an
org.eclipse.ocl.ecore.Variable.
Given that most users will use EMF or UML, it would be great if the doc
assumed one or the other and dispensed with the generic bits, which make
things look more complex than tney need to be.
Thanks for your help.
|
|
|
| Re: Context environments, package environments , variables, return types, doc [message #36939 is a reply to message #36527] |
Wed, 12 September 2007 14:30  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Larry,
Find some replies in-line, below.
HTH,
Christian
Larry Stevens wrote:
> In 1.0, working with EMF, we created an environment for each OCL
> expression and put that expression's variables in that environment.
>
> In 1.1, it appears that each context has a hidden sub-environment. Since
> you only have access to the OCL instance's root environment, variables are
> global to that instance and its root. I think this means that we create an
> ocl instance for each context to hold the expression's local variables,
> and let the helper create a basically superfluous subenvironment whose
> only purpose is to define self. If so, it would be great someday to be
> able to assign variables directly to the context environment.
I don't understand what you mean by "assign variables directly to the
context environment." Local variables, defined by "let" expressions, are
only visible in the context of a particular expression. You wouldn't want
them to persist in the classifier or package context.
> The doc talks about using package level environments to define namespaces.
> I can see how to create one, but I can't see how it works. Do I create the
> environment, then make it the root of an OCL instance, so that I end up
> with an OCL instance for each package? What use does it make of the
> package info?
This is the idea, yes. Most uses of the OCL object probably don't need the
root environment to be a package context, but it is useful when parsing OCL
documents that don't use the package declaration syntax *and* don't qualify
classifier names. In such cases, the environment will then have a default
package namespace in which to resolve these unqualified name references.
> The doc also recommends using a single OCL instance. How does that fit
> with the above? More generally, would I be better just working directly
> with environments and treating OCL and OCLHelper as throwaway convenience
> classes instead of trying to use a central OCL?
The documentation is addressing, here, what is anticipated as the most
common OCL processing scenario: a single model with a library of
constraints that need to be parsed and then evaluated repeatedly as
required by the client application. By using a single OCL object, any
additional operations an properties specified via "def:" expressions are
accessible to all constraints. Also, if parsing OCL documents, the OCL
will retain all of the constraints that it parsed.
This doesn't work so well if the application needs to provide an explicit
package context as discussed above because it is implicit in the OCL text.
An environment instance corresponds to a single classifier and/or package
context, so I suppose multiple discrete OCLs would be required here.
However, I expect that most models are rooted in a single package, anyway.
> Great idea to have bindings for specific metamodels, but many of the
> methods
> appear to return the generic supertype instead of the bound subtype so
> that I have to cast. E.g.,
> org.eclipse.ocl.ecore.VariableExp.getReferredVariable() returns an
> org.eclipse.ocl.expressions.Variable rather than an
> org.eclipse.ocl.ecore.Variable.
>
> Given that most users will use EMF or UML, it would be great if the doc
> assumed one or the other and dispensed with the generic bits, which make
> things look more complex than tney need to be.
The intent is that most clients shouldn't need to be aware of the fact that
the particles in their ASTs are org.eclipse.ocl.ecore.OCLExpression
instances instead of org.eclipse.ocl.OCLExpression<EClassifier>. There is
also potentially a large class of clients that will benefit from being
generic as the parser is. For example, much of what is intended for the
new OCL Tools component of MDT will apply equally well to UML as to Ecore
(viz. OCL-to-Java compilation, rich editors, debugging aids, ...). I
actually think that life is more simple when working only with the generic
API and being concerned with the Ecore/UML bindings only when deciding
which EnvironmentFactory implementation to use.
The particular case of the specific VariableExp returning the generic
Variable type is simply a consequence of the fact that Ecore doesn't (yet)
support redefinition of properties for refining their types, as does UML.
When and if that should change, then it certainly would be nice to take
advantage of it to clean up these mismatches.
>
> Thanks for your help.
|
|
|
Goto Forum:
Current Time: Wed Sep 11 13:25:59 GMT 2024
Powered by FUDForum. Page generated in 0.04145 seconds |
] 
Search
Help
Register
Login
Home
