Home » Modeling » Epsilon » About ETL rules
| About ETL rules [message #799764] |
Thu, 16 February 2012 09:30  |
 Alvaro Jimenez Rielo
Messages: 41
Registered: July 2009
Location: Rey Juan Carlos Universit... |
Member |
|
|
Hello everyone,
Now, I'm using ETL to create some transformations and while I was reading the Epsilon Book and the article "The Epsilon Transformation Language", I noticed that in ETL is possible to define: abstract rules, lazy rules, greedy rules, primary rules and matched rules.
I suppose that:
- abstract rules are rules which can be extended;
- lazy rules are rule which must be invoked (like ATL);
- matched rules are rule which are executed automatically when the engine finds a source element matching with the rule (like ATL).
But I don't know and I haven't found information about when greedy and primary rules are used. I understand that matched rules and primary rules are different because primary rule must be stereotyped by "@primary", is it correct?
Please, can someone help me with these doubts?
Thanks,
Álvaro
|
|
|
| Re: About ETL rules [message #800171 is a reply to message #799764] |
Thu, 16 February 2012 19:35  |
Mark Tippetts
Messages: 25
Registered: July 2009 |
Junior Member |
|
|
Alvaro,
My understanding is this: "Primary" rules are basically the opposite of "lazy" rules. In transformations and mergers, I've found that you can take one of two approaches to processing containment hierarchies: Either you have the leaf nodes resolve their parents (bottom-up), or you have root nodes resolve their children (top-down). Using the top-down approach, you set the rules for matching top-level elements as primary, and you set the rules for matching their children as lazy. Then you invoke the lazy rules explicitly by using equivalent() expressions in primary rules to process the child nodes. At least, that's what's worked for me. But I also find that the bottom-up approach works better in any case.
The "greedy" flag is only used in matching, not transformations or mergers. The greedy flag determines whether objects can match rules that are defined on their super-types. A greedy rule compares objects of the same kind, while a non-greedy rule only compares objects of exactly the same type.
"Matching" is not a flag on rules at all. Rather, each comparison results in a boolean result. Either a pair of objects matches, or not. The results of every comparison are recorded in the trace log of the comparison. Successful comparisons are recorded as a true match, and unsuccessful comparisons are recorded as a false match.
I hope this makes sense (and I hope it's right!).
Regards,
Mark
|
|
| | |
| Re: About ETL rules [message #800855 is a reply to message #800585] |
Fri, 17 February 2012 15:54 |
|
Hi,
Quote:I suppose that:
- abstract rules are rules which can be extended;
You are correct, but I would say that rather abstract rules MUST be extended, i.e. abstract rules are not invoked "individually", they are invoked when a rule that extends them is executed
Quote:- lazy rules are rule which must be invoked (like ATL);
Again you are correct. In general ETL is declarative. By annotating a rule as lazy your are making it imperative, i.e. source elements that have a type-of relationship with the type defined in the rule's sourceParameter (from) are only transformed if the equivalent(s) operation is invoked. From the Epsilon book: Unlike the main execution scheduling scheme discussed above, the equivalents() operation invokes both lazy and non-lazy rules.
In this example elements form the SysML model that have a kind-of relationship with sysmlModel!Block will only be transformed when the equivalent is used, in this case only the main block of the package is transformed.
rule InitialArchitecture
transform p : sysmlModel!Package
to a : Domain!Architecture {
a.blocks.add(p.getMainBlock().equivalent());
}
@lazy
rule StructuralBlock
transform sysmlBlock : sysmlModel!Block
to blk : Domain!Structural {
blk.name = sysmlBlock.name;
blk.id = sysmlBlock.id;
}
Quote:
- matched rules are rule which are executed automatically when the engine finds a source element matching with the rule (like ATL).
I am not sure what exactly do you mean by matched rules. Rules with no annotations or rules from the ECL language? If you are referring to the first from the Epsilon book, in section 5.5.2:
Quote:Following that, each non-abstract and non-lazy rule is executed for all
the elements on which it is applicable. To be applicable on a particular element, the element must have a type-of relationship with the type defined in the rule's sourceParameter and must also satisfy the guard of the rule (and all the rules it extends). (note that the Epsilon book originally says kind-of, see my comments on @greedy below)
In that case you are again correct. Since ETL is declarative it will transform all source elements that are source of non-abstrac and non-lazy rules.
If you are referring to ECL then.. well... match rules can also be annotated as lazy, greedy and abstract (ECL from the metamodel also as unique but that annotation is not present in the syntax of ECL in the book). The annotations work the same way as in ETL.
Quote:But I don't know and I haven't found information about when greedy and primary rules are used. I understand that matched rules and primary rules are different because primary rule must be stereotyped by "@primary", is it correct?
The greedy annotation "relaxes" the rule making it so that that now: To be applicable on a particular element, the element must have a kind-of relationship with the type defined in the rule's sourceParameter, i.e. any elements that have a type that inherits from the sourceparameter type will be transformed by the rule.
Finally, the primary annotation, as far as I know, is useful for resolving elements using the equivalent operation. From the Epsilon book: Also, when applied to a collection the equivalent() operation returns a flattened collection (as opposed to the result of equivalents() which is a Bag of Bags in this case).. However, you can not guarantee the order in which the equivalent elements are added to the set. In on execution of the transformation the result can be:
({Elements form ruleA}, {Elements form ruleC}, {Elements form ruleB})
and in the next execution:
({Elements form ruleC}, {Elements form ruleB}, {Elements form ruleA})
If you want that elements from the same rule are always returned first, this can make it easier/faster to filter your results you can use the primary annotation. If you annotate ruleA with @primary then in every execution of the transformation elements from ruleA will always be returned first in the collection.
Maybe a word form one of the Epsilon guys will verify this.
Regards,
Horacio Hoyos Rodriguez
Kinori Tech
Need professional support for Epsilon, EMF?
Go to: https://kinori.tech
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 06:17:36 GMT 2024
Powered by FUDForum. Page generated in 0.02862 seconds |
] 
Search
Help
Register
Login
Home
