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

[Joe Porter]

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
>