Home » Modeling » OCL » passing references as parameter(How can I pass a reference into an operation)
|Re: passing references as parameter [message #524010 is a reply to message #523907]
||Tue, 30 March 2010 10:02
| Martin H.
Registered: March 2010
I just tested the "self.A" query and it gives me an "org.eclipse.ocl.SemanticException: Unrecognized variable: (A)".
It looks to me like there is no implicit opposite...
Since I need to solve this problem for a project, I need a workaround like the one with the operation "reversenavigation(startClass : ?, referenceName : ?) : Set(?)" that gives me the reverse navigation. So how would I pass the needed parameters into it to evaluate something like "StartClass.allInstances()->select(x | x.referenceName = self)"? Is it possible to pass references into operations in ocl?
|Edward Willink wrote on Mon, 29 March 2010 10:26|
The way that definitely works is to select the A.allInstances() elements
that satisfy your predicate. However use of allInstances is strongly
discouraged because it scales badly.
The UML spec defines that in the absence of an explicit definition an
implicit opposite exists named by the opposite class. So self.A should
work from C. Please submit a Bugzilla if it doesn't.
More general treatment of opposites is an active OMG issue where there
is a particular requirement for such support for QVT. Expect an MDT/OCL
prototype in Iona.
On 29/03/2010 14:31, firstname.lastname@example.org wrote:
> Hello everyone,
> Assume we have the following situation:
> Our ECore meta model contains the classes A, B and C and two references
> a2c (from A to C) and b2c (from B to C).
> How would I define an operation in the context of C that gives me all
> instances of a given class referencing self via a given reference.
> What I need is something like self.reversenavigation(startClass : ?,
> reference : ?) : Set(?)
> Additionally I'd like to define this operation for all classes in my
> model, how can I do that (simply define it in the context of OCLAny type?).
> Thanks for your input in advance,
|Re: passing references as parameter [message #524136 is a reply to message #524132]
||Tue, 30 March 2010 21:04
|| Christian W. Damus
Registered: July 2009
Hi, Ed, Martin,|
This was initially implemented only in the UML binding of OCL because
UML has Associations, which EMOF/Ecore does not. Without associations,
EMOF doesn't have a concept of non-navigable end (there is no "end").
I think, Ed, that you were working in OMG to introduce non-navigable
opposites to EMOF. How's that going? It would, indeed, be nice to have
this inverse capability in the Ecore OCL.
On 30/03/10 04:50 PM, Ed Willink wrote:
> Hi Martin
>> If your meta-model extends EObject or you explicitly define it as such
>> through ParsingOptions.IMPLICIT_ROOT_CLASS and you are using EMF pre-M4
>> you should be able to use x.eGet(referenceName). Restoring this
>> functionality post M4 is work in progress
> I just investigated this again; it's a feature not a bug.
> If you explicitly define your meta-model as extending EObject through
> use of:
> you should be able to use x.eGet(referenceName).
> Ed Willink
|Re: passing references as parameter [message #524189 is a reply to message #524136]
||Wed, 31 March 2010 06:37
| Ed Willink
Registered: July 2009
> This was initially implemented only in the UML binding of OCL because
> UML has Associations, which EMOF/Ecore does not. Without associations,
> EMOF doesn't have a concept of non-navigable end (there is no "end").
Certainly no explicit concept, but the implicit class-named defaults
are applicable if you wish to extrapolate the imprecise specification.
> I think, Ed, that you were working in OMG to introduce non-navigable
> opposites to EMOF. How's that going? It would, indeed, be nice to have
> this inverse capability in the Ecore OCL.
There are two problems.
a) Persistence of the existence of an unnavigable opposite name. This is
solved by the Ecore oppositeRoleName EAnnotation and the EMOF Commented
Comment used in QVT 1.1. http://www.omg.org/issues/issue12800.txt
(Capturing Unnavigable Opposite Property Role Names) has not attracted
any discussion or action. See
b) Persistence of the usage of an opposite name. This requires that the
OCL AST support some form of 'boolean' isOpposite accompanying each
Property reference. QVTr 1.1 has introduced Key.oppositeParts to
complement Key.parts and PropertyTemplate.isOpposite. M2M/QVTd
introduces an OppositePropertyCallExp as a local workaround.
I can't find a relevant active OMG OCL issue.
http://www.omg.org/issues/issue8918.txt (Navigating across non navigable
associations) suggesting a concrete syntax change was dismissed in OCL
2.1 Ballot 2 just before I joined the RTF.
Your http://www.omg.org/issues/issue12795.txt (Special Types violate UML
Generalization Semantics) cuts to the heart of the AST inadequacies that
I'm hoping to resolve as part of
http://www.omg.org/issues/issue14861.txt (Inadequate definition of
run-time meta-model) for which I'm prototyping a solution in the MDT/OCL
ReflectiveLibrary branch. It is planned to commit this and make all
library behaviour model-driven in MDT/OCL 4.0.0 shortly after the Helios
Once a run-time meta-model OCLProperty unifies MOF/UML properties, OCL
'standard' library properties and user-defined constraints,
PropertyCallExp can be revised to support reference to an OCLProperty
and its opposite.
I have some Thales time to work on OMG issues so expect a further burst
of proposed OCL resolutions shortly.
|Re: passing references as parameter [message #526737 is a reply to message #526698]
||Mon, 12 April 2010 18:42
| Ed Willink
Registered: July 2009
Yes, in general oclOpposite could allow anarchy, but I wrote:
"Just needs the tooling to offer a little bit of special purpose
which can offer exactly the same user semantic quality.
Just needs the tooling to offer a little bit of special purpose semantic
An OppositePropertyCallExp requires a corresponding concrete syntax
which is a fairly 'major' OCL change and so might take some time to get
approved and widely supported. I'm not sure that OMG allows OCL 2.x to
introduce such an incompatility.
Syntactically there isn't very much difference between a.opposite(X::y)
with opposite a new reserved word and a.oclOpposite(X::y) with
oclOpposite a library function name. An oclOpposite library operation
could be introduced by OCL 2.x.
I've just started writing up a new batch of OCL 2.3 resolutions, so I'll
write up both and see what happens.
On 12/04/2010 16:51, Axel Uhl wrote:
> Hi Ed,
> I agree that subclassing PropertyCallExp and changing semantics is not a
> good idea and that subclassing NavigationCallExp is a better idea.
> As to the ModelElementLiteral, the problem is that instead of such a
> literal then any expression may be valid at that point that as its type
> has a model element; for example a variable expression where the
> variable is initialized by a ModelElementLiteral, or the result of some
> more complex expression such as if/else or even an operation call. With
> this, it again becomes statically impossible to determine which feature
> is being navigated. I understand that this sort of reflection increases
> flexibility. On the other hand, it cuts down our possibilities to
> understand at OCL compile time what the expressions do. Therefore, I'm
> in favor of introducing OppositePropertyCallExp, as you suggested as a
> subtype of NavigationCallExp.
> -- Axel
Current Time: Sun Dec 04 08:38:20 GMT 2016
Powered by FUDForum
. Page generated in 0.20161 seconds