| [Epsilon] Problem with ECL [message #383080] |
Tue, 13 May 2008 18:17  |
Eclipse User |
|
|
|
Originally posted by: ste_barr.cs.concordia.ca
Hello,
I'm trying to use ECL to help with some model merging. Unfortunately I'm
stuck.
My left model consits of a single class A, and the right a single class B.
I'm using the follow code (class.ecl) to compare them and print out the
match trace:
rule ClassA
match l : Left!Class with r : Right!Class {
compare : l.name = 'A' }
rule ClassB
match l : Left!Class with r : Right!Class {
compare : l.name = 'B' }
post {
-- Print name of matching elements and of the rule that matched them.
for (m in matchTrace.matches.select(m|m.isMatching)) {
(m.left.name + ' <' + m.getRule().name + '> ' +
m.right.name).println();
}
}
I think that the four element pairings should cause each rule to fire
once, so the output is a surprise to me:
A <ClassA> A
A <ClassA> B
Where are the B to A, B to B pairings? Why did rule ClassA match A with B?
And why does the second rule never fire?
I can't help put think that I'm missing something really basic here, but I
have spent a bit of time trying to unravel this. Thanks for taking a look.
--Steve
P.S. I couldn't get "m.rules.first().name" as given in the Complete OO to
DB comparison to work, which is why I'm using "m.getRule().name" Could
this be a source of trouble?
|
|
|
| Re: [Epsilon] Problem with ECL [message #383081 is a reply to message #383080] |
Tue, 13 May 2008 18:39  |
 Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Steve,
I can't reproduce this. For a Left model that contains only one Class A
and a Right model that contains only one Class B I get the following result:
A <ClassA> B
which is correct. There is only one pair to be compared (why did you
expect 4?), and when the ClassA rule is executed it returns true and so
A and B are recorded as matching.
I suspect that both of your two models have 2 classes (A and B) each.
That would explain the result: the 4 pairs first pass from rule ClassA
which characterizes the A<->A and A<->B pairs as matching, and the B<->A
and B<->B pairs as non-matching (your clause is l.name = 'A') and as a
result, since at that point the engine has decided about all pairs, rule
ClassB is not needed and thus is not executed.
Cheers,
Dimitrios
Steve Barrett wrote:
> Hello,
>
> I'm trying to use ECL to help with some model merging. Unfortunately I'm
> stuck.
>
> My left model consits of a single class A, and the right a single class
> B. I'm using the follow code (class.ecl) to compare them and print out
> the match trace:
>
>
> rule ClassA
> match l : Left!Class with r : Right!Class {
> compare : l.name = 'A' }
>
> rule ClassB
> match l : Left!Class with r : Right!Class {
> compare : l.name = 'B' }
>
> post {
> -- Print name of matching elements and of the rule that matched them.
> for (m in matchTrace.matches.select(m|m.isMatching)) {
> (m.left.name + ' <' + m.getRule().name + '> ' + m.right.name).println();
> }
> }
>
>
> I think that the four element pairings should cause each rule to fire
> once, so the output is a surprise to me:
>
>
> A <ClassA> A
> A <ClassA> B
>
>
> Where are the B to A, B to B pairings? Why did rule ClassA match A with
> B? And why does the second rule never fire?
>
> I can't help put think that I'm missing something really basic here, but
> I have spent a bit of time trying to unravel this. Thanks for taking a
> look.
>
> --Steve
>
> P.S. I couldn't get "m.rules.first().name" as given in the Complete OO
> to DB comparison to work, which is why I'm using "m.getRule().name"
> Could this be a source of trouble?
>
>
>
|
|
|
| Re: [Epsilon] Problem with ECL [message #383082 is a reply to message #383081] |
Tue, 13 May 2008 19:23 |
| Eclipse User |
|
|
|
Originally posted by: ste_barr.cs.concordia.ca
I knew it was simple!
You are right I do have an A and a B in both models (I've been staring at
it too long...). Your explanation of the second rule not needing to be
invoked makes total sense. Thank you.
--Steve
|
|
|
|
| Re: [Epsilon] Problem with ECL [message #383084 is a reply to message #383083] |
Wed, 14 May 2008 01:58 |
| Eclipse User |
|
|
|
Originally posted by: ste_barr.cs.concordia.ca
I'm playing with EML now Dimitrios. Something doesn't seem right however.
When I try to merge the MergeOO example only the <Models> rule matches,
and the resulting Merged.model is simply a union of *all* the elements in
both models. I end up with duplicate School and Teacher classes, and
String Datatypes.
I was expecting something more like I see explained in the example at
http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt /epsilon/org.epsilon.eclipse.help/index.html
For reference I've pasted in the text view of the output model:
<?xml version="1.0" encoding="ASCII"?>
<OO:Model xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:OO="OO"
xmi:id="_O6fjQCFYEd2zH6RpYvdvlA" name="educational">
<contents xsi:type="OO:Class" xmi:id="_O6gKUCFYEd2zH6RpYvdvlA"
name="Student" isAbstract="false">
<features xsi:type="OO:Reference" xmi:id="_O6gxYCFYEd2zH6RpYvdvlA"
name="supervisor" type="_O6hYcCFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
<contents xsi:type="OO:Class" xmi:id="_O6m4ACFYEd2zH6RpYvdvlA"
name="School" isAbstract="false">
<features xsi:type="OO:Attribute" xmi:id="_O6m4ASFYEd2zH6RpYvdvlA"
name="address" type="_O6nfECFYEd2zH6RpYvdvlA" isMany="false"/>
<features xsi:type="OO:Attribute" xmi:id="_O6xQECFYEd2zH6RpYvdvlA"
name="acceptsPostcodes" type="_O6nfECFYEd2zH6RpYvdvlA" isMany="true"/>
<features xsi:type="OO:Reference" xmi:id="_O6x3ICFYEd2zH6RpYvdvlA"
name="employees" type="_O6yeMCFYEd2zH6RpYvdvlA" isMany="true"/>
</contents>
<contents xsi:type="OO:Class" xmi:id="_O6lC0CFYEd2zH6RpYvdvlA"
name="Module" isAbstract="false">
<features xsi:type="OO:Attribute" xmi:id="_O6lC0SFYEd2zH6RpYvdvlA"
name="subject" type="_O6lp4CFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
<contents xsi:type="OO:Class" xmi:id="_O606cCFYEd2zH6RpYvdvlA"
name="Support" extends="_O6yeMCFYEd2zH6RpYvdvlA" isAbstract="false">
<features xsi:type="OO:Attribute" xmi:id="_O606cSFYEd2zH6RpYvdvlA"
name="role" type="_O6nfECFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
<contents xsi:type="OO:Datatype" xmi:id="_O62IkSFYEd2zH6RpYvdvlA"
name="Real"/>
<contents xsi:type="OO:Datatype" xmi:id="_O6nfECFYEd2zH6RpYvdvlA"
name="String"/>
<contents xsi:type="OO:Class" xmi:id="_O6zFQCFYEd2zH6RpYvdvlA"
name="Person" extendedBy="_O6yeMCFYEd2zH6RpYvdvlA" isAbstract="true">
<features xsi:type="OO:Attribute" xmi:id="_O6zsUCFYEd2zH6RpYvdvlA"
name="details" type="_O6nfECFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
<contents xsi:type="OO:Datatype" xmi:id="_O64k0CFYEd2zH6RpYvdvlA"
name="Boolean"/>
<contents xsi:type="OO:Class" xmi:id="_O6imkCFYEd2zH6RpYvdvlA"
name="Class" isAbstract="false">
<features xsi:type="OO:Attribute" xmi:id="_O6imkSFYEd2zH6RpYvdvlA"
name="grade" type="_O6jNoCFYEd2zH6RpYvdvlA" isMany="false"/>
<features xsi:type="OO:Reference" xmi:id="_O6j0sCFYEd2zH6RpYvdvlA"
name="students" type="_O6gKUCFYEd2zH6RpYvdvlA" isMany="true"/>
<features xsi:type="OO:Reference" xmi:id="_O6kbwCFYEd2zH6RpYvdvlA"
name="modules" type="_O6lC0CFYEd2zH6RpYvdvlA" isMany="true"/>
</contents>
<contents xsi:type="OO:Class" xmi:id="_O6yeMCFYEd2zH6RpYvdvlA"
name="Employee" extends="_O6zFQCFYEd2zH6RpYvdvlA"
extendedBy="_O60TYCFYEd2zH6RpYvdvlA _O606cCFYEd2zH6RpYvdvlA"
isAbstract="true">
<features xsi:type="OO:Attribute" xmi:id="_O62IkCFYEd2zH6RpYvdvlA"
name="salary" type="_O62IkSFYEd2zH6RpYvdvlA" isMany="false"/>
<features xsi:type="OO:Reference" xmi:id="_O62voCFYEd2zH6RpYvdvlA"
name="manager" type="_O6yeMCFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
<contents xsi:type="OO:Class" xmi:id="_O60TYCFYEd2zH6RpYvdvlA"
name="Teacher" extends="_O6yeMCFYEd2zH6RpYvdvlA" isAbstract="false"/>
<contents xsi:type="OO:Datatype" xmi:id="_O6lp4CFYEd2zH6RpYvdvlA"
name="String"/>
<contents xsi:type="OO:Class" xmi:id="_O6hYcCFYEd2zH6RpYvdvlA"
name="Teacher" isAbstract="false">
<features xsi:type="OO:Reference" xmi:id="_O6h_gCFYEd2zH6RpYvdvlA"
name="teaches" type="_O6imkCFYEd2zH6RpYvdvlA" isMany="true"/>
</contents>
<contents xsi:type="OO:Datatype" xmi:id="_O6jNoCFYEd2zH6RpYvdvlA"
name="Integer"/>
<contents xsi:type="OO:Class" xmi:id="_O65L4CFYEd2zH6RpYvdvlA"
name="School" isAbstract="false">
<features xsi:type="OO:Reference" xmi:id="_O65y8CFYEd2zH6RpYvdvlA"
name="classes" type="_O6imkCFYEd2zH6RpYvdvlA" isMany="true"/>
<features xsi:type="OO:Reference" xmi:id="_O66aACFYEd2zH6RpYvdvlA"
name="principal" type="_O6hYcCFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
</OO:Model>
|
|
|
|
|
| Re: [Epsilon] Problem with ECL [message #617621 is a reply to message #383080] |
Tue, 13 May 2008 18:39 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Steve,
I can't reproduce this. For a Left model that contains only one Class A
and a Right model that contains only one Class B I get the following result:
A <ClassA> B
which is correct. There is only one pair to be compared (why did you
expect 4?), and when the ClassA rule is executed it returns true and so
A and B are recorded as matching.
I suspect that both of your two models have 2 classes (A and B) each.
That would explain the result: the 4 pairs first pass from rule ClassA
which characterizes the A<->A and A<->B pairs as matching, and the B<->A
and B<->B pairs as non-matching (your clause is l.name = 'A') and as a
result, since at that point the engine has decided about all pairs, rule
ClassB is not needed and thus is not executed.
Cheers,
Dimitrios
Steve Barrett wrote:
> Hello,
>
> I'm trying to use ECL to help with some model merging. Unfortunately I'm
> stuck.
>
> My left model consits of a single class A, and the right a single class
> B. I'm using the follow code (class.ecl) to compare them and print out
> the match trace:
>
>
> rule ClassA
> match l : Left!Class with r : Right!Class {
> compare : l.name = 'A' }
>
> rule ClassB
> match l : Left!Class with r : Right!Class {
> compare : l.name = 'B' }
>
> post {
> -- Print name of matching elements and of the rule that matched them.
> for (m in matchTrace.matches.select(m|m.isMatching)) {
> (m.left.name + ' <' + m.getRule().name + '> ' + m.right.name).println();
> }
> }
>
>
> I think that the four element pairings should cause each rule to fire
> once, so the output is a surprise to me:
>
>
> A <ClassA> A
> A <ClassA> B
>
>
> Where are the B to A, B to B pairings? Why did rule ClassA match A with
> B? And why does the second rule never fire?
>
> I can't help put think that I'm missing something really basic here, but
> I have spent a bit of time trying to unravel this. Thanks for taking a
> look.
>
> --Steve
>
> P.S. I couldn't get "m.rules.first().name" as given in the Complete OO
> to DB comparison to work, which is why I'm using "m.getRule().name"
> Could this be a source of trouble?
>
>
>
|
|
|
| Re: [Epsilon] Problem with ECL [message #617624 is a reply to message #383081] |
Tue, 13 May 2008 19:23 |
| Eclipse User |
|
|
|
Originally posted by: ste_barr.cs.concordia.ca
I knew it was simple!
You are right I do have an A and a B in both models (I've been staring at
it too long...). Your explanation of the second rule not needing to be
invoked makes total sense. Thank you.
--Steve
|
|
|
|
| Re: [Epsilon] Problem with ECL [message #617626 is a reply to message #383083] |
Wed, 14 May 2008 01:58 |
| Eclipse User |
|
|
|
Originally posted by: ste_barr.cs.concordia.ca
I'm playing with EML now Dimitrios. Something doesn't seem right however.
When I try to merge the MergeOO example only the <Models> rule matches,
and the resulting Merged.model is simply a union of *all* the elements in
both models. I end up with duplicate School and Teacher classes, and
String Datatypes.
I was expecting something more like I see explained in the example at
http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt /epsilon/org.epsilon.eclipse.help/index.html
For reference I've pasted in the text view of the output model:
<?xml version="1.0" encoding="ASCII"?>
<OO:Model xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:OO="OO"
xmi:id="_O6fjQCFYEd2zH6RpYvdvlA" name="educational">
<contents xsi:type="OO:Class" xmi:id="_O6gKUCFYEd2zH6RpYvdvlA"
name="Student" isAbstract="false">
<features xsi:type="OO:Reference" xmi:id="_O6gxYCFYEd2zH6RpYvdvlA"
name="supervisor" type="_O6hYcCFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
<contents xsi:type="OO:Class" xmi:id="_O6m4ACFYEd2zH6RpYvdvlA"
name="School" isAbstract="false">
<features xsi:type="OO:Attribute" xmi:id="_O6m4ASFYEd2zH6RpYvdvlA"
name="address" type="_O6nfECFYEd2zH6RpYvdvlA" isMany="false"/>
<features xsi:type="OO:Attribute" xmi:id="_O6xQECFYEd2zH6RpYvdvlA"
name="acceptsPostcodes" type="_O6nfECFYEd2zH6RpYvdvlA" isMany="true"/>
<features xsi:type="OO:Reference" xmi:id="_O6x3ICFYEd2zH6RpYvdvlA"
name="employees" type="_O6yeMCFYEd2zH6RpYvdvlA" isMany="true"/>
</contents>
<contents xsi:type="OO:Class" xmi:id="_O6lC0CFYEd2zH6RpYvdvlA"
name="Module" isAbstract="false">
<features xsi:type="OO:Attribute" xmi:id="_O6lC0SFYEd2zH6RpYvdvlA"
name="subject" type="_O6lp4CFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
<contents xsi:type="OO:Class" xmi:id="_O606cCFYEd2zH6RpYvdvlA"
name="Support" extends="_O6yeMCFYEd2zH6RpYvdvlA" isAbstract="false">
<features xsi:type="OO:Attribute" xmi:id="_O606cSFYEd2zH6RpYvdvlA"
name="role" type="_O6nfECFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
<contents xsi:type="OO:Datatype" xmi:id="_O62IkSFYEd2zH6RpYvdvlA"
name="Real"/>
<contents xsi:type="OO:Datatype" xmi:id="_O6nfECFYEd2zH6RpYvdvlA"
name="String"/>
<contents xsi:type="OO:Class" xmi:id="_O6zFQCFYEd2zH6RpYvdvlA"
name="Person" extendedBy="_O6yeMCFYEd2zH6RpYvdvlA" isAbstract="true">
<features xsi:type="OO:Attribute" xmi:id="_O6zsUCFYEd2zH6RpYvdvlA"
name="details" type="_O6nfECFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
<contents xsi:type="OO:Datatype" xmi:id="_O64k0CFYEd2zH6RpYvdvlA"
name="Boolean"/>
<contents xsi:type="OO:Class" xmi:id="_O6imkCFYEd2zH6RpYvdvlA"
name="Class" isAbstract="false">
<features xsi:type="OO:Attribute" xmi:id="_O6imkSFYEd2zH6RpYvdvlA"
name="grade" type="_O6jNoCFYEd2zH6RpYvdvlA" isMany="false"/>
<features xsi:type="OO:Reference" xmi:id="_O6j0sCFYEd2zH6RpYvdvlA"
name="students" type="_O6gKUCFYEd2zH6RpYvdvlA" isMany="true"/>
<features xsi:type="OO:Reference" xmi:id="_O6kbwCFYEd2zH6RpYvdvlA"
name="modules" type="_O6lC0CFYEd2zH6RpYvdvlA" isMany="true"/>
</contents>
<contents xsi:type="OO:Class" xmi:id="_O6yeMCFYEd2zH6RpYvdvlA"
name="Employee" extends="_O6zFQCFYEd2zH6RpYvdvlA"
extendedBy="_O60TYCFYEd2zH6RpYvdvlA _O606cCFYEd2zH6RpYvdvlA"
isAbstract="true">
<features xsi:type="OO:Attribute" xmi:id="_O62IkCFYEd2zH6RpYvdvlA"
name="salary" type="_O62IkSFYEd2zH6RpYvdvlA" isMany="false"/>
<features xsi:type="OO:Reference" xmi:id="_O62voCFYEd2zH6RpYvdvlA"
name="manager" type="_O6yeMCFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
<contents xsi:type="OO:Class" xmi:id="_O60TYCFYEd2zH6RpYvdvlA"
name="Teacher" extends="_O6yeMCFYEd2zH6RpYvdvlA" isAbstract="false"/>
<contents xsi:type="OO:Datatype" xmi:id="_O6lp4CFYEd2zH6RpYvdvlA"
name="String"/>
<contents xsi:type="OO:Class" xmi:id="_O6hYcCFYEd2zH6RpYvdvlA"
name="Teacher" isAbstract="false">
<features xsi:type="OO:Reference" xmi:id="_O6h_gCFYEd2zH6RpYvdvlA"
name="teaches" type="_O6imkCFYEd2zH6RpYvdvlA" isMany="true"/>
</contents>
<contents xsi:type="OO:Datatype" xmi:id="_O6jNoCFYEd2zH6RpYvdvlA"
name="Integer"/>
<contents xsi:type="OO:Class" xmi:id="_O65L4CFYEd2zH6RpYvdvlA"
name="School" isAbstract="false">
<features xsi:type="OO:Reference" xmi:id="_O65y8CFYEd2zH6RpYvdvlA"
name="classes" type="_O6imkCFYEd2zH6RpYvdvlA" isMany="true"/>
<features xsi:type="OO:Reference" xmi:id="_O66aACFYEd2zH6RpYvdvlA"
name="principal" type="_O6hYcCFYEd2zH6RpYvdvlA" isMany="false"/>
</contents>
</OO:Model>
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02852 seconds
] 
Search
Help
Register
Login
Home
