Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » passing references as parameter(How can I pass a reference into an operation)
passing references as parameter [message #523810] Mon, 29 March 2010 09:31 Go to next message
Martin H. is currently offline Martin H.
Messages: 3
Registered: March 2010
Junior Member
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,
Sincerely
Re: passing references as parameter [message #523905 is a reply to message #523810] Mon, 29 March 2010 14:58 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4013
Registered: July 2009
Senior Member
Hi bp2009g1

The way that definitely works is to select the A.allInstances() 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 in QVT. Expect an MDT/OCL
prototype in Iona.




On 29/03/2010 14:31, bp2009g1@hpi.uni-potsdam.de 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,
> Sincerely
Re: passing references as parameter [message #523907 is a reply to message #523810] Mon, 29 March 2010 10:26 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4013
Registered: July 2009
Senior Member
Hi bp2009g1

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.

Regards

Ed Willink


On 29/03/2010 14:31, bp2009g1@hpi.uni-potsdam.de 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,
> Sincerely
Re: passing references as parameter [message #524010 is a reply to message #523907] Tue, 30 March 2010 06:02 Go to previous messageGo to next message
Martin H. is currently offline Martin H.
Messages: 3
Registered: March 2010
Junior Member
Hello Ed,

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?

Best regards,
Martin

Edward Willink wrote on Mon, 29 March 2010 10:26
Hi bp2009g1

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.

Regards

Ed Willink


On 29/03/2010 14:31, bp2009g1@hpi.uni-potsdam.de 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,
> Sincerely

Re: passing references as parameter [message #524127 is a reply to message #524010] Tue, 30 March 2010 11:54 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4013
Registered: July 2009
Senior Member
Hi Martin

> 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...

Sorry I should have checked. I have added a (failing) test to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=251621 Unnavigable
opposites are currently only supported for the UML binding.

> 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?

I have raised an explicit OMG issue to introduce support for
x.oclGet(referenceName) analoguous to eGet. The possibility of oclGet
has already been raised in
http://www.omg.org/issues/ocl2-rtf.open.html#Issue14861

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
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=297011).

Regards

Ed Willink
Re: passing references as parameter [message #524132 is a reply to message #524127] Tue, 30 March 2010 16:50 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4013
Registered: July 2009
Senior Member
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
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=297011).

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:

ParsingOptions.setOption(ocl.getEnvironment(),
ParsingOptions.implicitRootClass(ocl.getEnvironment()),
EcorePackage.Literals.EOBJECT);

you should be able to use x.eGet(referenceName).

Regards

Ed Willink
Re: passing references as parameter [message #524136 is a reply to message #524132] Tue, 30 March 2010 17:04 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 768
Registered: July 2009
Senior Member
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.

Cheers,

Christian


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
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=297011).
>
> 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:
>
> ParsingOptions.setOption(ocl.getEnvironment(),
> ParsingOptions.implicitRootClass(ocl.getEnvironment()),
> EcorePackage.Literals.EOBJECT);
>
> you should be able to use x.eGet(referenceName).
>
> Regards
>
> Ed Willink
Re: passing references as parameter [message #524189 is a reply to message #524136] Wed, 31 March 2010 02:37 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4013
Registered: July 2009
Senior Member
Hi Christian

> 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
https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998

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
3.0.0 release.

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.

Regards

Ed Willink
Re: passing references as parameter [message #524521 is a reply to message #524189] Thu, 01 April 2010 05:01 Go to previous messageGo to next message
Martin H. is currently offline Martin H.
Messages: 3
Registered: March 2010
Junior Member
Hi Ed & Christian,

First of all thanks for your input. Unfortunately we encountered a more general problem. If we pass a parameter to an operation this would create an OclExpression AST node. But we need to statically determine which reference we're navigating in reverse without any knowledge of context instances.

It basically boils down to extending the ocl syntax to include an explicit notation for reverse navigation and adding a new AST node similar to the OppositePropertyCallExp introduced by QVT.

Best regards,
Martin
Re: passing references as parameter [message #524674 is a reply to message #524521] Thu, 01 April 2010 14:32 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4013
Registered: July 2009
Senior Member
Hi Martin

What are your timescales for this?

I hope to be able to look at this in a month or two and maybe have an
MDT/OCL solution aligned with a proposed OMG resolution at about M1 or M2.

I'm not comfortable with M2M/QVTd's OppositePropertyCallExp solution
because it doesn't tackle the more general problem and exhibits the very
poor practice of a subtype making inconsistent changes to inherited
semantics. OppositePropertyCallExp might be valid if it inherited from
NavigationCallExp rather than PropertyCallExp but that may need some
minor OCLAnalyzer or OCLParser signature changes which were impossible
for M2M/QVTd to do in isolation.

OMG/QVTr defines the something.opposite(MyClass::myProperty) notation.
This would be more logically something.oclOpposite(MyClass::myProperty)
in OMG/OCL, so that Classifier::oclOpposite(Property) is a standard
library function.

Wow! AST problem solved without any change (except a ModelElementLiteral
that already appeared to be necessary). Just needs the tooling to offer
a little bit of special purpose semantic validation.

Regards

Ed Willink

On 01/04/2010 10:01, Martin H. wrote:
> Hi Ed & Christian,
>
> First of all thanks for your input. Unfortunately we encountered a more
> general problem. If we pass a parameter to an operation this would
> create an OclExpression AST node. But we need to statically determine
> which reference we're navigating in reverse without any knowledge of
> context instances.
>
> It basically boils down to extending the ocl syntax to include an
> explicit notation for reverse navigation and adding a new AST node
> similar to the OppositePropertyCallExp introduced by QVT.
>
> Best regards,
> Martin
Re: passing references as parameter [message #526698 is a reply to message #524674] Mon, 12 April 2010 11:51 Go to previous messageGo to next message
Axel Uhl is currently offline Axel Uhl
Messages: 40
Registered: July 2009
Member
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.

Best,
-- Axel
Re: passing references as parameter [message #526737 is a reply to message #526698] Mon, 12 April 2010 14:42 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4013
Registered: July 2009
Senior Member
Hi Axel

Yes, in general oclOpposite could allow anarchy, but I wrote:

"Just needs the tooling to offer a little bit of special purpose
semantic validation."

which can offer exactly the same user semantic quality.

Just needs the tooling to offer a little bit of special purpose semantic
validation.

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.

Regards

Ed Willink

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.
>
> Best,
> -- Axel
Re: passing references as parameter [message #526751 is a reply to message #526737] Mon, 12 April 2010 15:28 Go to previous messageGo to next message
Axel Uhl is currently offline Axel Uhl
Messages: 40
Registered: July 2009
Member
Hi Ed,

not sure I made my point clear. Even a keyword oclOpposite(<exp>) would leave open how the <exp> is provided. Static analysis may be difficult. Are you implying that you would want to constrain how this <exp> is to be provided, namely as a ModelReferenceExp or similar?

Or are you suggesting to introduce the keyword "oclOpposite", together with specific concrete syntax that only allows for ModelReferenceExp as argument?
Re: passing references as parameter [message #526756 is a reply to message #526751] Mon, 12 April 2010 15:37 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4013
Registered: July 2009
Senior Member
Hi Axel

> Or are you suggesting to introduce the keyword "oclOpposite", together
> with specific concrete syntax that only allows for ModelReferenceExp as
> argument?

I'm suggesting that

- OCL 2.x introduces the non-breaking oclOpposite function.
[- perhaps OCL 3.0 introduces a breaking opposite syntax change.]

- minimally compliant tooling has all the inadequacies you identify

- good tooling behaves as if oclOpposite was a selectively reserved keyword

Ed
Re: passing references as parameter [message #526771 is a reply to message #526756] Mon, 12 April 2010 16:59 Go to previous messageGo to next message
Axel Uhl is currently offline Axel Uhl
Messages: 40
Registered: July 2009
Member
Ed,

have you considered a syntax that remains backward-compatible in the sense that it can never collide with any OCL expression that is valid in the present OCL specification?

For example, what about

exp~oppositeRef

The tilde doesn't seem to be a valid character in OCL so far. Therefore, the above expression will not parse in current OCL parsers but could be made to parse in a newer release.

It would allow OCL compilers to understand the type of the expression. Therefore, no casts with oclAsType would be required and static analysis would be easier.

Best,
-- Axel
Re: passing references as parameter [message #526791 is a reply to message #523810] Mon, 12 April 2010 18:27 Go to previous messageGo to next message
Axel Uhl is currently offline Axel Uhl
Messages: 40
Registered: July 2009
Member
Oh, and BTW, I guess it may be most convenient if the standard "." notation also worked for the opposites if the name is unique. Therefore, it would be the parser's responsibility to find out whether the identifier following the "." references a "forward" EReference, an EAttribute or the implicit opposite of any of the EReferences. Would that be possible?
Re: passing references as parameter [message #526812 is a reply to message #526771] Tue, 13 April 2010 00:55 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4013
Registered: July 2009
Senior Member
Hi Axel

QVTo in a related context uses ~ to indicate 'not-navigable' in a
property declaration, which si a bit confusing as a usage as navigate.

I considered

..~ or .! or .< or -< or <-

as variant navigation operators.

<- is ambiguous

I'm not that keen on subtle short forms since they can make code
unreadable by intuition and impede language expansion.

..< and -< might get in the way of a generic types extension.

It might be better to have this discussion on the ocl2-rtf list to see
if anyone else has strong opinions.

Please comment there when I post an issue and then a proposed resolution.

Regards

Ed Willink



On 12/04/2010 21:59, Axel Uhl wrote:
> Ed,
>
> have you considered a syntax that remains backward-compatible in the
> sense that it can never collide with any OCL expression that is valid in
> the present OCL specification?
>
> For example, what about
>
> exp~oppositeRef
>
> The tilde doesn't seem to be a valid character in OCL so far. Therefore,
> the above expression will not parse in current OCL parsers but could be
> made to parse in a newer release.
>
> It would allow OCL compilers to understand the type of the expression.
> Therefore, no casts with oclAsType would be required and static analysis
> would be easier.
>
> Best,
> -- Axel
Previous Topic:OCL in Ecore using 3.6M6
Next Topic:Ecore data types map to OCL type
Goto Forum:
  


Current Time: Wed Jul 30 13:30:50 EDT 2014

Powered by FUDForum. Page generated in 0.02638 seconds