| OCL features, Acceleo and Sirius [message #1798136] |
Tue, 13 November 2018 03:01  |
Eclipse User |
|
|
|
Hi,
I created a metamodel with a number of concepts having derived OCL properties. Next, I created a graphical editor for that kind of models using Sirius. In the label expression, I referred to the derived properties. There I ran into some strange things.
With this property, everything works as expected:
property operatesOn1 : ADTO[?] { derived readonly transient volatile }
{
initial:
self.parameters->first().oclAsType(system::TypedParameter).typereference.type.oclAsType(dds::ADTO);
}
However, some dereference '.' operates might return null or undefined so I added som safe navigation:
property operatesOn : ADTO[?] { derived readonly transient volatile }
{
initial:
self?.parameters->first()?.oclAsType(system::TypedParameter)?.typereference?.type?.oclAsType(dds::ADTO);
}
This does not work. My suspicion in that the safe navigation is not supported when evaluating the OCL query via the Acceleo language.
OK, then I'll rewrite it.
property operatesOn2 : ADTO[?] { derived readonly transient volatile }
{
initial:
if (self.parameters->size()>0 and self.parameters->first().oclIsKindOf(system::TypedParameter))
then
let firstpar = self.parameters->first().oclAsType(system::TypedParameter)
in
if (firstpar.typereference.oclIsUndefined() or firstpar.typereference.type.oclIsUndefined())
then
null
else
let firstpartype = firstpar.typereference.type
in
if (firstpartype.oclIsKindOf(dds::ADTO))
then
firstpartype.oclAsType(dds::ADTO)
else
null
endif
endif
else
null
endif;
}
This one also does not work. Maybe the 'let' expression is in the way. Let's remove it:
property operatesOn3 : ADTO[?] { derived readonly transient volatile }
{
initial:
if (self.parameters->size()>0 and self.parameters->first().oclIsKindOf(system::TypedParameter))
then
if ((self.parameters->first().oclAsType(system::TypedParameter).typereference.oclIsUndefined()) or
(self.parameters->first().oclAsType(system::TypedParameter).typereference.type.oclIsUndefined()))
then
null
else
if (self.parameters->first().oclAsType(system::TypedParameter).typereference.type.oclIsKindOf(dds::ADTO))
then
self.parameters->first().oclAsType(system::TypedParameter).typereference.type.oclAsType(dds::ADTO)
else
null
endif
endif
else
null
endif;
}
This one works again. I verified using the semantic property vies in Sirius that each of the 'operatesOn' variants delivers the same result so the ocl expressions themselves seem to be correct.
Is this indeed caused by the fact that OCL code, invokved by the Acceleo interpreter, does not support 'let' and safe navigation?
Greetings,
Wilbert.
|
|
|
| Re: OCL features, Acceleo and Sirius [message #1798138 is a reply to message #1798136] |
Tue, 13 November 2018 04:20  |
| Eclipse User |
|
|
|
Hi
Yes. Acceleo uses the Classic Eclipse OCL that has been maintained but not evolved for many years now. As such it has none of the prototyping for a next OCL in the Unified / Pivot-based OCL.
Therefore
- no inference of let variable types
- no safe navigation
- no .....
- no API instability
Some newer functions such as selectByKind have been added. They may help a bit.
Regards
Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.06992 seconds
Home