<p class="MsoNormal">Hi Joe!<br>
I have no doubt that a single model component (thus, single type)
transformation can work but my input model (see a simplified view in
attachment) contains components from both types. As you can see it has 2
MobBlock, 4 ModParts and one equation (ModelEquation). Each block and part has
its own equation (not seen) and various numbers interconnected ports from
different types. It's consistent with the Metamodel and it's what I have to
transform now. I want to build a transformation that can handle this level of complexity
and higher from the input model and, of course, a lower level of complexity as
the one you mentioned. The issue of unique identification of of metamodel
elements (see my email below and the screen capture attached) is capital when
having multiple type of components. I really need to know if GREAT can handle
this and how. I’ll also welcome any workaround strategy. </p>
<p class="MsoNormal">Thanks,</p>
<p class="MsoNormal">Leonard</p>
<br><br><div class="gmail_quote">2012/3/8 Joe Porter <span dir="ltr"><<a href="mailto:joe.porter@gmail.com" target="_blank">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>
That transformation is way too complex.<br>
If I understand you correctly, then you need to do something like this:<br>
<br>
If Model contains a single ModComponent that is of type ModPart, then<br>
get the Equation objects for ModPart and its associated Block, and<br>
create ports based on attributes in the ModEquation and the knowledge<br>
that it belongs to a ModPart object.<br>
<br>
If Model contains a single ModComponent that is of type ModBlock, then<br>
get the Equation objects for ModBlock and its associated Block, and<br>
create ports based on attributes in the ModEquation and the knowledge<br>
that it belongs to a ModBlock object.<br>
<br>
<this one is still unclear, so tell me if I'm on the right track><br>
If Model contains exactly two ModComponents, one of type ModPart and<br>
one of type ModBlock, then get the Equation objects for both objects<br>
and their associated Blocks, and create ports in each associated<br>
ModEquation based on attributes in the ModPart and ModBlock, and the<br>
knowledge that Model contains both objects.<br>
<br>
Does that sound right? If not, please correct it. What if Model<br>
contains three or more ModComponents? What do you expect to happen,<br>
or is it disallowed somehow? What if there are two ModParts and one<br>
ModBlock, or vice-versa?<br>
<br>
Sorry for the spotty responses - I'm sitting in a sponsor review<br>
meeting today and tomorrow.<br>
<div><div><br>
-Joe<br>
<br>
2012/3/8 Léonard PETNGA <<a href="mailto:lpetnga@gmail.com" target="_blank">lpetnga@gmail.com</a>>:<br>
> Sorry,<br>
> Please find it in attachment...<br>
> Leonard<br>
><br>
><br>
> 2012/3/8 Joe Porter <<a href="mailto:joe.porter@gmail.com" target="_blank">joe.porter@gmail.com</a>><br>
>><br>
>> 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" target="_blank">lpetnga@gmail.com</a>>:<br>
>> > Hi Joe,<br>
>> > Thank you for your feedback. Using cases was a way for me to speed up<br>
>> > the<br>
>> > transformation process based on the type of patterns contained in the<br>
>> > 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,<br>
>> > ports<br>
>> > and constraint blocks. The rule below is the perfect illustration of<br>
>> > 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<br>
>> > 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<br>
>> > need<br>
>> > to differentiate a Block created for ModPart from a one created for<br>
>> > ModBlock<br>
>> > as they don't accept the same type of ports. I actually added a number<br>
>> > to<br>
>> > the class name to ease the tracking process from one rule to another,<br>
>> > but as<br>
>> > said previously, Visual Studio compiler does NOT recognize these<br>
>> > elements<br>
>> > and treats them as undeclared variabls; consequently, the compilation<br>
>> > 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>
>> > 2012/3/6 Joe Porter <<a href="mailto:joe.porter@gmail.com" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">lpetnga@gmail.com</a>>:<br>
>> >> >>> ><br>
>> >> >>> > Hi everyone! I'm a new user of the GME/GREAT tool suite and I<br>
>> >> >>> > have<br>
>> >> >>> > some<br>
>> >> >>> > questions for you guys.<br>
>> >> >>> > 1. I have written a rule containing a pattern including an<br>
>> >> >>> > 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<br>
>> >> >>> > 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<br>
>> >> >>> > 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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>