Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » OCLinEcore editor hungry? (eats characters)
OCLinEcore editor hungry? (eats characters) [message #1015030] Wed, 27 February 2013 09:05 Go to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi,

I noticed that something seems to go wrong with the OCLinEcore editor during the serialisation to the ecore xmi format.

Consider the .oclinecore file in attachment, and save it as ecore file. Then reopen the .ecore file using the OCLinecore editor, and you will notice that it contains (syntax) errors. Indeed, it seems that some expressions have just disappeared with respect to the original contents (note that I'm not worrying about the disappeared newlines).

 diff -w components.oclinecore components.ecore.txt 
5c5
< 		operation extendPaths(currentC : Component, currentP : OrderedSet(OrderedSet(Component)))
---
> 		operation extendPaths(currentC : Component, currentP)
8,12c8
< 				if currentC.targets->size() = 1
< 				then currentP->select(subset | subset->includes(currentC.sources))->collect(c | c->append(currentC)) 
< 				else currentP->append(OrderedSet{currentC}) 
< 				endif;
---
> 				if currentC.targets->size() = 1 then currentP->select(subset | subset->includes(currentC.sources))->collect(c | c->append(currentC)) else currentP->append(OrderedSet{currentC}) endif;
26c22
< 				self.components->iterate(c; pts : OrderedSet(OrderedSet(Component)) = OrderedSet{OrderedSet{firstComponent}} | Container::extendPaths(c, pts));
---
> 				self.components->iterate(c; pts : OrderedSet(OrderedSet(Component)) = OrderedSet{OrderedSet{firstComponent}} | extendPaths(c, pts));


I'm running Kepler M5, using the latest nightly build of OCL, but I previously noticed similar issues on juno.
Any ideas?

TIA,

Klaas

Edit: I now also noticed that the return type of the operation (OrderedSet(OrderedSet(Component)) of the operation was previously eaten, so that line in the oclinecore file should actually look like

operation extendPaths(currentC : Component, currentP : OrderedSet(OrderedSet(Component))) : OrderedSet(OrderedSet(Component))


instead of the one above, but that doesn't change the problem. It made me also realise that this eating is probably due to the fact that the OCLinEcore parser sees this as a valid syntax, but this is actually not the case as the orderedSet type is not part of the eCore language (Is this actually a case where projectional editing systems such as MPS would have their benefits?). Also, is this a use case (complex helper operation) where it would be better to recur to the CompleteOCL editor, where I _can_ define the above operation as a helper operation using the def: construct?

Also, it doesn't explain why some statements in the body disappear (I reworked the example using a helper class Path--see the new attachments---), but the issue still occurs there...

[Updated on: Wed, 27 February 2013 12:27]

Report message to a moderator

Re: OCLinEcore editor hungry? (eats characters) [message #1015175 is a reply to message #1015030] Wed, 27 February 2013 16:25 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Thanks. https://bugs.eclipse.org/bugs/show_bug.cgi?id=401922 raised.

Regards

Ed Willink


On 27/02/2013 09:05, Klaas Gadeyne wrote:
> package components : components = 'platform:/resource/Components/model/components.oclinecore'
> {
> class Container
> {
> operation extendPaths(currentC : Component, currentP)
> {
> body:
> if currentC.targets->size() = 1 then currentP->select(subset | subset->includes(currentC.sources))->collect(c | c->append(currentC)) else currentP->append(OrderedSet{currentC}) endif;
> }
> property components : Component[*] { ordered composes };
> property firstComponent : Component;
> property lastComponent : Component;
> attribute requiredNumPaths : Integer;
> attribute numPaths : Integer { derived transient volatile }
> {
> derivation:
> self.components->reject(c | c = lastComponent)->iterate(c; numPaths : Integer = 1 | numPaths + c.targets->size() - 1);
> }
> property paths : Component[*] { ordered derived transient volatile }
> {
> derivation:
> self.components->iterate(c; pts : OrderedSet(OrderedSet(Component)) = OrderedSet{OrderedSet{firstComponent}} | extendPaths(c, pts));
> }
> invariant numpathsinv: numPaths = requiredNumPaths;
> invariant firstComponent0Sources: self.firstComponent.sources->size() = 0;
> invariant lastComponent0Targets: self.lastComponent.targets->size() = 0;
> }
> class Component
> {
> attribute name : String[?];
> property targets#sources : Component[*] { ordered };
> property sources#targets : Component[*] { ordered };
> property followers : Component[*] { ordered derived transient volatile }
> {
> derivation: self.targets->union(self.targets->closure(targets));
> }
> }
> }

Report message to a moderator

Re: OCLinEcore editor hungry? (eats characters) [message #1015206 is a reply to message #1015030] Wed, 27 February 2013 18:10 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

I'm amazed how well such complicated code seems to work.

The problem is that once

operation extendPaths(currentC : Component, currentP :
OrderedSet(OrderedSet(Component)))

becomes an EOperation, we hit the problem that Ecore (like UML) does not
support nested collections.

I've unified OCL nested collections and UML bounded collection within
the OCL editors and PIvot model and evaluation, but as you've
discovered, I've yet to synthesize a solution for the missing Ecore
support. https://bugs.eclipse.org/bugs/show_bug.cgi?id=401938 raised.

For now the woraround may be to hide the nested collection inside a Tuple.

Regards

Ed Willink


On 27/02/2013 09:05, Klaas Gadeyne wrote:
> Hi,
>
> I noticed that something seems to go wrong with the OCLinEcore editor during the serialisation to the ecore xmi format.
>
> Consider the .oclinecore file in attachment, and save it as ecore file. Then reopen the .ecore file using the OCLinecore editor, and you will notice that it contains (syntax) errors. Indeed, it seems that some expressions have just disappeared with respect to the original contents.
>
>
> diff -w components.oclinecore components.ecore.txt
> 5c5
> < operation extendPaths(currentC : Component, currentP : OrderedSet(OrderedSet(Component)))
> ---
>> operation extendPaths(currentC : Component, currentP)
> 8,12c8
> < if currentC.targets->size() = 1
> < then currentP->select(subset | subset->includes(currentC.sources))->collect(c | c->append(currentC))
> < else currentP->append(OrderedSet{currentC})
> < endif;
> ---
>> if currentC.targets->size() = 1 then currentP->select(subset | subset->includes(currentC.sources))->collect(c | c->append(currentC)) else currentP->append(OrderedSet{currentC}) endif;
> 26c22
> < self.components->iterate(c; pts : OrderedSet(OrderedSet(Component)) = OrderedSet{OrderedSet{firstComponent}} | Container::extendPaths(c, pts));
> ---
>> self.components->iterate(c; pts : OrderedSet(OrderedSet(Component)) = OrderedSet{OrderedSet{firstComponent}} | extendPaths(c, pts));
>
>
> I'm running Kepler M5, using the latest nightly build of OCL, but I previously noticed similar issues on juno.
> Any ideas?
>
> TIA,
>
> Klaas
>

Report message to a moderator

Re: OCLinEcore editor hungry? (eats characters) [message #1015221 is a reply to message #1015206] Wed, 27 February 2013 19:42 Go to previous message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi Ed,
Ed Willink wrote on Wed, 27 February 2013 13:10
Hi

I'm amazed how well such complicated code seems to work.

I'm amazed how fast you reply Smile Thx for that!

Quote:

The problem is that once

operation extendPaths(currentC : Component, currentP :
OrderedSet(OrderedSet(Component)))

becomes an EOperation, we hit the problem that Ecore (like UML) does not
support nested collections.

I've unified OCL nested collections and UML bounded collection within
the OCL editors and PIvot model and evaluation, but as you've
discovered, I've yet to synthesize a solution for the missing Ecore
support. https://bugs.eclipse.org/bugs/show_bug.cgi?id=401938 raised.


It's nice to hear that this should be able to work using the pivot model! So far, I didn't really understand the pivot meta-model very well, but if it means your could do these things in OCLinEcore, it would be great indeed!

Quote:

For now the woraround may be to hide the nested collection inside a Tuple.


As I didn't think this would be possible, I've put the constraints in a separate OCL file (probably more on that later Wink. However, I created a small test to check if this would work with the tuple, but I was bitten by the first problem again (<https://bugs.eclipse.org/bugs/show_bug.cgi?id=401922>)...

So, for now I'll think I'll stay with the completeOCL approach...

Regards,

Klaas

Report message to a moderator

Previous Topic:AST AbstractVisitor get occurances of operation arguments in operation's body
Next Topic:Generating .oclinecore file from Ecore programmatically
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Wed Apr 24 15:52:36 GMT 2024

Powered by FUDForum. Page generated in 0.02606 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly