| Re: [henshin-user] Nested application conditions in Henshin diagrams? |
Hi,sorry for joining this a bit late. I feel I need to comment on the example rule you added in the first place. You said it never matched, which did not really make sense to me. So I rebuilt your example (hopefully identically) and for me the rule works as expected.
- The rule always finds a match as long as there is a transition. The applicability of a rule is not dependent on whether there is a match of the multi-rule.
- Three incoming and one outgoing place are connected to a transition; only on incoming place got tokens: The multi-rule does not find a match as the require-part and the source-part can not be matched at the same time.
- Three incoming and one outgoing place are connected to a transition; two incoming places got tokens: All tokens are transferred as the places with tokens are alternately matched for the require-part and the source-part.
You need to consider that the multi-rule creates a match with ONE mapping for each element of the multi-rule and finds. So the require-part can not ensure that all places have a token before you even start to match the rest of the rule. Instead it only ensures that ONE of the other incoming places needs a token, when you found a fitting source place. This is trivially fulfilled if you have at least two incoming places with a token in it.
The descriptions of multi-rules often talk about them being a forAll operator. But that does not mean something can be done for all elements at once. Unfortunately, you can only iterate over the elements and handle them independently.
I'll add the metamodel and rule for reference. Best wishes, Stefan@Steffen: I think the above problem is actually the reason for the OCL condition in our use case.
On 20.10.2018 09:29, Zschaler, Steffen wrote:
Hi all,I’m trying to figure out how to do nested application conditions in the Henshin diagram editor. I was hoping that this could be done the same way that I can nest multi-rules, using paths in the labels. However, that doesn’t seem to do anything useful. Is there a different way of doing this?Specifically, I’m trying to write a standard Petri Net firing rule. For this, I would like to add a NAC that there are no source places with no tokens. So, roughly,¬\exists({Transition—Place} à ¬\exists{Transition—Place—Token})I’ve tried using a require* instead, as below, but that rule never matches, even when all source places have a token…Any suggestions? Many thanks, Steffen Dr. rer. nat. Steffen Zschaler AHEA Senior Lecturer King's College London Department of Informatics Email szschaler@xxxxxxx Phone +44 (020) 7848 1513 WWW http://www.steffen-zschaler.de/ _______________________________________________ henshin-user mailing list henshin-user@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/henshin-user
Attachment:
fire.png
Description: PNG image
Attachment:
petrinet.png
Description: PNG image
