Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Epsilon » About ETL rules
About ETL rules [message #799764] Thu, 16 February 2012 09:30 Go to next message
Alvaro Jimenez Rielo is currently offline 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 Go to previous messageGo to next message
Mark Tippetts is currently offline 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 #800585 is a reply to message #800171] Fri, 17 February 2012 08:45 Go to previous messageGo to next message
Alvaro Jimenez Rielo is currently offline Alvaro Jimenez Rielo
Messages: 41
Registered: July 2009
Location: Rey Juan Carlos Universit...
Member
Thank you for your answer, Mark.

But I want to point some notes about it:

As we can read in "The Epsilon Transformation Language": abstract, lazy and primary are optional attributes of a rule (I suppose that "a rule" means "a normal matched rule", i.e. without flag).

In http://www.eclipse.org/epsilon/doc/etl/ we can read that a feature of ETL is: "Lazy and greedy rules", so greedy rules is not only used for matching.

With respect to primary rules, I've just read in Epsilon Book:
"With regard to the ordering of the results of the equivalents() operations,
the returned elements appear in the respective order of the rules
that have created them. An exception to this occurs when one of the rules
is declared as primary, in which case its results precede the results of all
other rules."

Regards,
Álvaro
Re: About ETL rules [message #800836 is a reply to message #800585] Fri, 17 February 2012 15:27 Go to previous messageGo to next message
Mark Tippetts is currently offline Mark Tippetts
Messages: 25
Registered: July 2009
Junior Member
Alvero,

You're absolutely right. In the Epsilon Book, the abstract syntax diagram shows the greedy flag, but the concrete syntax does not list it as an annotation. I looked at the source code just now, and there is indeed support for the greedy attribute. In fact, lazy, greedy, and abstract turn out to be supported by any rule that subclasses org.eclipse.epsilon.erl.rules.ExtensibleNamedRule That's very useful to know. I guess it's true what they say, that the best way to learn is by explaining something to others. Thanks!

Mark
Re: About ETL rules [message #800855 is a reply to message #800585] Fri, 17 February 2012 15:54 Go to previous messageGo to next message
Horacio Hoyos is currently offline Horacio Hoyos
Messages: 155
Registered: October 2009
Senior Member

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
EngD Student
University Of York
Re: About ETL rules [message #801417 is a reply to message #800855] Sat, 18 February 2012 10:48 Go to previous messageGo to next message
Dimitris Kolovos is currently offline Dimitris Kolovos
Messages: 876
Registered: July 2009
Senior Member
That all sounds right. Many thanks Horacio!

Cheers,
Dimitris
Re: About ETL rules [message #801424 is a reply to message #801417] Sat, 18 February 2012 11:00 Go to previous message
Alvaro Jimenez Rielo is currently offline Alvaro Jimenez Rielo
Messages: 41
Registered: July 2009
Location: Rey Juan Carlos Universit...
Member
Thanks for your all answers Smile
Between all of us, we have reached a right agreement about the ETL rules meaning.

Regards,
Álvaro
Previous Topic:How to migrate complex models
Next Topic:EVL Validation on Diagram with references
Goto Forum:
  


Current Time: Tue Sep 30 17:54:26 GMT 2014

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

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