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

[Léonard PETNGA]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.isis.vanderbilt.edu/pipermail/great-users/attachments/20120308/c0bea496/attachment.html