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

[Joe Porter]

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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen captures Model transformation(1).docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 1000815 bytes
Desc: not available
Url : http://list.isis.vanderbilt.edu/pipermail/great-users/attachments/20120306/8a7e8e27/attachment-0001.bin