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

Thu Mar 8 11:04:26 CST 2012

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.isis.vanderbilt.edu/pipermail/great-users/attachments/20120308/cea930ea/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen capture 2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 265713 bytes
Desc: not available
Url : http://list.isis.vanderbilt.edu/pipermail/great-users/attachments/20120308/cea930ea/attachment-0001.bin 