Home » Modeling » ATL » [ATL] Matching in a called rule(clarification about the language)
| [ATL] Matching in a called rule [message #1801296] |
Wed, 16 January 2019 09:41  |
 Jeremy Buisson
Messages: 2
Registered: January 2019 |
Junior Member |
|
|
Dear all,
I apologize if my question seems dumb, but the language documentation is not clear to me.
I would like to make a rule that creates various target model elements, depending on the type of the source element being transformed. Possibly with additional conditions. If I understand well, I can easily do so by means of a group of matched rules.
And I want to have different transformation of similar source model elements, depending on the context where these source elements appear. If I understand well, I can easily do so by means of called rules.
But, if I still understand correctly, called rules cannot match the source model element against some condition. And matched rules are applied the same anywhere in the source model, regardless of any context.
Is anybody able to clarify if I understand correctly? And, if possible, give a hint how I could proceed?
Thanks.
|
|
|
| Re: [ATL] Matching in a called rule [message #1801326 is a reply to message #1801296] |
Wed, 16 January 2019 20:53  |
|
Jeremy Buisson wrote on Wed, 16 January 2019 10:41Dear all,
I apologize if my question seems dumb, but the language documentation is not clear to me.
I would like to make a rule that creates various target model elements, depending on the type of the source element being transformed. Possibly with additional conditions. If I understand well, I can easily do so by means of a group of matched rules.
Correct.
Quote:
And I want to have different transformation of similar source model elements, depending on the context where these source elements appear. If I understand well, I can easily do so by means of called rules.
You can also do this with matched rules and lazy rules.
Quote:
But, if I still understand correctly, called rules cannot match the source model element against some condition. And matched rules are applied the same anywhere in the source model, regardless of any context.
Is anybody able to clarify if I understand correctly? And, if possible, give a hint how I could proceed?
Thanks.
Called rules must be invoked from a specific context, and cannot specify any input filter expression.
Matched rules can take an input OCL condition to filter which elements will match against the rule. Here's an example that filters input elements with an OCL expression:
https://www.eclipse.org/atl/documentation/basicExamples_Patterns/article.php?file=Tree2List/index.html
If you cannot specify which elements should be transformed by a matched rule through its input filter expression, you may use lazy rules instead. Lazy rules must be invoked, just like called rules, but with a few more options.
Since EMFTVM, lazy rules can also have input filter expressions. Unique lazy rules are injective, and will only create the output elements once for each unique input pattern.
Cheers,
Dennis
|
|
|
| Re: [ATL] Matching in a called rule [message #1801659 is a reply to message #1801326] |
Thu, 24 January 2019 09:54 |
Jeremy Buisson
Messages: 2
Registered: January 2019 |
Junior Member |
|
|
Hello,
Thanks for the reply, which helps me clarify ideas. So I still have questions.
Assume now that the context I was talking about was not within the source models, but within the target models. That is, for one source model element, I would like to have several rules that create various target elements, each being inserted at various locations in the target models.
I understand that I can do so by means of called rules, but there is no filtering on input elements. At best, I can proceed with imperative code looking like do { if (x.oclIsTypeOf(...) else if (x.oclIsTypeOf(...) else ... }
I think that I cannot do so by means of matched rules, but still unsure. Indeed, I do not know how I could name each of the target elements created from a single source element. It is still unclear what is the semantics of ATL when several matched rules trigger for a single source element.
Maybe lazy rules are the solution. But I have to admit that I still not clearly understand how they differ from called rules since, in the documentation, lazy rules have to be called like called rules. Your answer makes me wonder how the match and filtering can be used in the case of lazy rules. Indeed, I would expect the execution engine select the lazy rule whose from clause matches the source element and whose condition evaluates to true. But, because I have to name the lazy rule I would like to call, and because I cannot give the same name to several rules, I am pretty sure I don't understand well. Could you please help me try to better understand this point?
|
|
|
| Re: [ATL] Matching in a called rule [message #1801721 is a reply to message #1801659] |
Fri, 25 January 2019 09:06 |
|
The rationale behind ATL is that you should never navigate the output model(s). This works very well for matched rules and unique lazy rules, as you can always navigate to the input model elements, and then trace it to the generated output elements from there. However, trouble begins when you need to access the output of called rules: if you need to access their output from outside the rule itself, you're out of luck. EMFTVM even forbids navigating output models.
For this reason, you should try to write most of your code using matched rules and (unique) lazy rules. In addition, you can use trace model reflection in EMFTVM: this will work even for regular lazy rules, but not for called rules. Called rules never generate traces. In fact, in EMFTVM lazy rules can do anything that called rules can do, so called rules are only useful if you need to do special performance tuning with your transformation.
Finally about lazy rule filtering: lazy rules must always be invoked explicitly, just like called rules. If you specify an input filter expression on the lazy rule (EMFTVM only), then the rule itself will check the input with which it was invoked. If the input does not match the filter expression, the lazy rule will do nothing and simply return OclUndefined. N.B. in EMFTVM, lazy rules also check the type of the input elements: if the type does not match the rule's from clause, the rule will not trigger, and also returns OclUndefined! Called rules in EMFTVM behave similar to helper methods: if the input element types do not match the rule/method signature, you'll get an "operation not found" error. If you want to specify the same lazy rule with different input element types, you can use virtual dispatch in combination with rule inheritance since ATL v.4.0.
Cheers,
Dennis
[Updated on: Fri, 25 January 2019 09:09] Report message to a moderator |
|
|
Goto Forum:
Current Time: Sat Nov 11 08:20:06 GMT 2023
Powered by FUDForum. Page generated in 0.02018 seconds |
] 
Search
Help
Register
Login
Home
