[great-users] Handling of abstract classes and transformation debugging

[Joe Porter]

Leonard,

That transformation is way too complex.
If I understand you correctly, then you need to do something like this:

If Model contains a single ModComponent that is of type ModPart, then
get the Equation objects for ModPart and its associated Block, and
create ports based on attributes in the ModEquation and the knowledge
that it belongs to a ModPart object.

If Model contains a single ModComponent that is of type ModBlock, then
get the Equation objects for ModBlock and its associated Block, and
create ports based on attributes in the ModEquation and the knowledge
that it belongs to a ModBlock object.

<this one is still unclear, so tell me if I'm on the right track>
If Model contains exactly two ModComponents, one of type ModPart and
one of type ModBlock, then get the Equation objects for both objects
and their associated Blocks, and create ports in each associated
ModEquation based on attributes in the ModPart and ModBlock, and the
knowledge that Model contains both objects.

Does that sound right? If not, please correct it.  What if Model
contains three or more ModComponents?  What do you expect to happen,
or is it disallowed somehow?  What if there are two ModParts and one
ModBlock, or vice-versa?

Sorry for the spotty responses - I'm sitting in a sponsor review
meeting today and tomorrow.

-Joe

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