Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » QVT-Relations » Problem with Setting a Property with cardinality 1..*
Problem with Setting a Property with cardinality 1..* [message #1808906] Thu, 04 July 2019 09:47 Go to next message
Steffen Becker is currently offline Steffen BeckerFriend
Messages: 31
Registered: July 2009
Member
Dear QVTd team,

I have a meta-model for FSMs and petri nets in my lectures. The petri net contains a Transition meta-class with "from" and "to" properties of cardinality *.

The following rule now makes problem.
	top relation TransitionToTransition {
		label:String;
		sourceTPN:pn::Place{};
		destTPN:pn::Place{};
		checkonly domain fsm t:fsm::Transition {
			input=label,
			from=sourceTFSM:fsm::State{},
			to=destTFSM:fsm::State{},
			fsm=f:fsm::FSM{}
		};
		enforce domain petri p:pn::Transition {
			input=label,
			from=sourceTPN,
			to=destTPN,
			 net=pn:pn::PetriNet{}
		};
		when {
			AutomataToNet(f,pn);
			StateToPlace(sourceTFSM,sourceTPN);
			StateToPlace(destTFSM,destTPN);
		}
	}


The problem is the assignment to from and to. The engine tries to assign the object on the right hand side to the list of the left hand side instead of ensuring that the object on the right hand side gets included in the list on the left hand side if it is not included yet. If create a set on the right hand side and assign it, it works, but in my interpretation this is against the specs.

I can attach the example project containing the fix for further investigations.

Best wishes,
Steffen


Re: Problem with Setting a Property with cardinality 1..* [message #1808912 is a reply to message #1808906] Thu, 04 July 2019 12:27 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Nice to hear from a real user. Thanks for a real repro that just works...

Now that Eclipse is on 3 month releases, QVTd is going through many small evolutions, often involving a behind the scenes clean up.

What you are referring to seems like what I call a partial assignment (not well-defined in the QVTd spec). Simplistically a pattern such as "aCollection = aCollectionElement" is partial and so the resulting aCollection includes aCollectionElement; multiple partial assignments are permitted; all partial assignments must be able to occur before any read of the result. In contrast "aCollection = anotherCollection" is non-partial and so the resulting Collection is precisely set to the content of anotherCollection; multiple non-partial assignments are pretty dubious, but not necessarily diagnosed accurately.

I recall fixing some issues with partial assignments a couple of months ago prior to 2019-06. It seems to work for me. What version are you using?

You might want to enable YED/DOT graphs in the launch so that you get internal debug of the underlying QVTs, that you might find fun. I find it essential for development debugging. Manually prettified QVTs of your example attached.

p.from seems to be a Collection with a thin unidirectional navigation from sourceTPN. The DOT variant has a label on this line: «part» (seems the YED serializer needs some work to make the guillemets work). But part of a Collection is I think what you want.

http://www.eclipse.org/mmt/qvt/docs/ICGT2019/GraphicalQVT.pdf should provide some clues about the QVTs semantics/visuals. (Composition diamonds are new since that paper.)

(The next milestone has code that responds to https://issues.omg.org/browse/QVT14-64 making the klunky {} at the end of childless PropertyTemplaeItems optional.)

Regards

Ed Willink

Re: Problem with Setting a Property with cardinality 1..* [message #1808929 is a reply to message #1808912] Thu, 04 July 2019 16:35 Go to previous messageGo to next message
Steffen Becker is currently offline Steffen BeckerFriend
Messages: 31
Registered: July 2009
Member
Dear Ed,

thank you for your prompt reply. It is an example I use for years now and which I so far let the students evaluate with the now very outdated mediniQVT. So, I just tested it briefly this morning whether it works now in Eclipse. I had an Eclipe 2019-03 with the QVTd installed via the integrated installer.

I now tried it also with 2019-06 and there it works :-) So, obviously it got fixed in between.

Do you also have a working UML2RBMS for your engine? Then from next semester onwards I could drop medini from the tool chain I use.

Best wishes,
Steffen
Re: Problem with Setting a Property with cardinality 1..* [message #1808948 is a reply to message #1808929] Thu, 04 July 2019 19:29 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Steffen

(Sometimes there is a two day delay in the RSS feed propagating, so if you're in a hurry Bugzilla is much more reliable.)

Good that it's fixed. Very good that you can consider Eclipse QVTd as a replacement for MediniQVT, but until I am confident enough to change the version to 1.0, I cannot recommend it that strongly. A lot still to do.

There are at least two QVTd UML2RDBMS'. A QVTc one is available from the examples. A QVTr one is available from org.eclipse.qvtd.xtext.qvtrelation.tests. Two QVTi ones split off from early QVTc/QVTr implementations and provide tests of older idioms. Note that there is no standard 'Simple'UML2RDBMS. Each author chooses which difficulties to concentrate on. I've even seen one that was so simple there was only a composition tree and no cross-references!

Regards

Ed Willink
Previous Topic:Problem with Parsing XML-Files
Next Topic:Pivot to CS for QVTd transformations
Goto Forum:
  


Current Time: Fri Apr 19 20:07:24 GMT 2024

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

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

Back to the top