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.
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 #524136 is a reply to message #524132] |
Tue, 30 March 2010 21:04 |
|
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 06:37 |
Ed Willink
Messages: 7655
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 #526737 is a reply to message #526698] |
Mon, 12 April 2010 18:42 |
Ed Willink
Messages: 7655
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
|
|
| | | | | |
Goto Forum:
Current Time: Tue Apr 23 08:50:05 GMT 2024
Powered by FUDForum. Page generated in 0.04760 seconds |
] 
Search
Help
Register
Login
Home
