Sorry,<br>Please find it in attachment...<br>Leonard<br><br><div class="gmail_quote">2012/3/8 Joe Porter <span dir="ltr"><<a href="mailto:joe.porter@gmail.com">joe.porter@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Leonard,<br>
<br>
Can you please find a different way to attach your image? It showed<br>
up as a giant text string full of binary data on my Gmail.<br>
<br>
Thanks,<br>
-Joe<br>
<br>
2012/3/8 Léonard PETNGA <<a href="mailto:lpetnga@gmail.com">lpetnga@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hi Joe,<br>
> Thank you for your feedback. Using cases was a way for me to speed up the<br>
> transformation process based on the type of patterns contained in the input<br>
> model after execution of rule 2. It was also an attempt to address the<br>
> complexity added by the redundant use of elements suh as ModEquations, ports<br>
> and constraint blocks. The rule below is the perfect illustration of that<br>
> complexity I need your help to sort out.<br>
> On the input model side (above the guard), I need to differentiate a<br>
> ModBlock equation from a ModPart equation. The differences in ModEquation<br>
> attributes (especially the value of "nbConnect") can result in different<br>
> numbers of StandardPort which I actually want to create only for the<br>
> ConstraintBlock corresponding to that ModEquation. I'ved recalled the<br>
> crosslink (as a bound) constructd when creating Blocks from Component<br>
> (abstract) in rule 2. On the output model side (below the guard) I also need<br>
> to differentiate a Block created for ModPart from a one created for ModBlock<br>
> as they don't accept the same type of ports. I actually added a number to<br>
> the class name to ease the tracking process from one rule to another, but as<br>
> said previously, Visual Studio compiler does NOT recognize these elements<br>
> and treats them as undeclared variabls; consequently, the compilation fails<br>
> and the .exe file is not generated. What is/are the solution(s) to this<br>
> differentiation problem?<br>
> Being able to capture these differences is particularly critical in<br>
> specifying guard conditions and attributes mapping. Is there any OCL/MCL<br>
> expression/command to work around this issue?<br>
> Thanks.<br>
> Leonard<br>
><br>
><br>
><br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> 2012/3/6 Joe Porter <<a href="mailto:joe.porter@gmail.com">joe.porter@gmail.com</a>><br>
>><br>
>> Leonard,<br>
>><br>
>> Sorry it has taken so long to get back to you. For the reference of<br>
>> the list users, I attached your original notes file.<br>
>><br>
>> Rule 2: The creation mechanism ensures you will have uniqueness, since<br>
>> each ModComponent creates a block. The Crosslink keeps those two<br>
>> objects associated (ModComponent <-> Block) so you can quickly look up<br>
>> the Block that goes with each ModComponent, or vice-versa.<br>
>><br>
>> Rule 3: The cardinality for ModEquation isn't quite right. 1..* means<br>
>> "one or more". You want to use 0..1, which means just one. I would<br>
>> leave rules 2 and 3 separate, but I don't have a solid technical<br>
>> reason why. I will ask.<br>
>><br>
>> On the case question, why do you need a case? Can you just create one<br>
>> rule to handle creating ports corresponding to ModPart, and another to<br>
>> create ports corresponding to ModBlock?<br>
>><br>
>> -Joe<br>
>><br>
>> 2012/3/2 Léonard PETNGA <<a href="mailto:lpetnga@gmail.com">lpetnga@gmail.com</a>>:<br>
>> > Sorry, I forgot to attach the file...<br>
>> ><br>
>> ><br>
>> > 2012/3/2 Léonard PETNGA <<a href="mailto:lpetnga@gmail.com">lpetnga@gmail.com</a>><br>
>> >><br>
>> >> Hi Joe,<br>
>> >> Please find the requested information in attachment.<br>
>> >> Thank you!<br>
>> >> Leonard<br>
>> >><br>
>> >><br>
>> >> 2012/3/1 Joe Porter <<a href="mailto:joe.porter@gmail.com">joe.porter@gmail.com</a>><br>
>> >>><br>
>> >>> Leonard,<br>
>> >>><br>
>> >>> Can you post a few screen capture images of the metamodel structure<br>
>> >>> you're interested in and the proposed rules?<br>
>> >>><br>
>> >>> Thanks,<br>
>> >>> -Joe<br>
>> >>><br>
>> >>> 2012/3/1 Léonard PETNGA <<a href="mailto:lpetnga@gmail.com">lpetnga@gmail.com</a>>:<br>
>> >>> ><br>
>> >>> > Hi everyone! I'm a new user of the GME/GREAT tool suite and I have<br>
>> >>> > some<br>
>> >>> > questions for you guys.<br>
>> >>> > 1. I have written a rule containing a pattern including an abstract<br>
>> >>> > class<br>
>> >>> > (at level n). I want GREAT to use this rule to create an object<br>
>> >>> > based<br>
>> >>> > on the<br>
>> >>> > pattern provided as input. However, in my next rule, I need to get<br>
>> >>> > access to<br>
>> >>> > the inherited classes (level n-1) in the next rule ie the real<br>
>> >>> > objects<br>
>> >>> > abstracted. Since GREAT does not allow me to represent inheritance<br>
>> >>> > (as<br>
>> >>> > specified in the Metamodel) can I just (in the next rule) connect<br>
>> >>> > the<br>
>> >>> > real<br>
>> >>> > objects at n-1 to the real one at n+1 as children and parent by<br>
>> >>> > bypassing<br>
>> >>> > the abstract class? If no please clarify this point to me. I will<br>
>> >>> > also<br>
>> >>> > welcome any more efficient way to handle this kind of situation.<br>
>> >>> > 2. Is there anyway to "debug" or test the transformation rule by<br>
>> >>> > rule<br>
>> >>> > prior<br>
>> >>> > to running the Master interpreter?<br>
>> >>> > Thank,<br>
>> >>> > Leonard<br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > _______________________________________________<br>
>> >>> > great-users mailing list<br>
>> >>> > <a href="mailto:great-users@list.isis.vanderbilt.edu">great-users@list.isis.vanderbilt.edu</a><br>
>> >>> > <a href="http://list.isis.vanderbilt.edu/mailman/listinfo/great-users" target="_blank">http://list.isis.vanderbilt.edu/mailman/listinfo/great-users</a><br>
>> >>> ><br>
>> >>> _______________________________________________<br>
>> >>> great-users mailing list<br>
>> >>> <a href="mailto:great-users@list.isis.vanderbilt.edu">great-users@list.isis.vanderbilt.edu</a><br>
>> >>> <a href="http://list.isis.vanderbilt.edu/mailman/listinfo/great-users" target="_blank">http://list.isis.vanderbilt.edu/mailman/listinfo/great-users</a><br>
>> >><br>
>> >><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > great-users mailing list<br>
>> > <a href="mailto:great-users@list.isis.vanderbilt.edu">great-users@list.isis.vanderbilt.edu</a><br>
>> > <a href="http://list.isis.vanderbilt.edu/mailman/listinfo/great-users" target="_blank">http://list.isis.vanderbilt.edu/mailman/listinfo/great-users</a><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> great-users mailing list<br>
>> <a href="mailto:great-users@list.isis.vanderbilt.edu">great-users@list.isis.vanderbilt.edu</a><br>
>> <a href="http://list.isis.vanderbilt.edu/mailman/listinfo/great-users" target="_blank">http://list.isis.vanderbilt.edu/mailman/listinfo/great-users</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> great-users mailing list<br>
> <a href="mailto:great-users@list.isis.vanderbilt.edu">great-users@list.isis.vanderbilt.edu</a><br>
> <a href="http://list.isis.vanderbilt.edu/mailman/listinfo/great-users" target="_blank">http://list.isis.vanderbilt.edu/mailman/listinfo/great-users</a><br>
><br>
_______________________________________________<br>
great-users mailing list<br>
<a href="mailto:great-users@list.isis.vanderbilt.edu">great-users@list.isis.vanderbilt.edu</a><br>
<a href="http://list.isis.vanderbilt.edu/mailman/listinfo/great-users" target="_blank">http://list.isis.vanderbilt.edu/mailman/listinfo/great-users</a><br>
</div></div></blockquote></div><br>