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

Mon Mar 12 13:07:07 CDT 2012

Hi Joe!
I have no doubt that a single model component (thus, single type)
transformation can work but my input model (see a simplified view in
attachment) contains components from both types. As you can see it has 2
MobBlock, 4 ModParts and one equation (ModelEquation). Each block and part
has its own equation (not seen) and various numbers interconnected ports
from different types. It's consistent with the Metamodel and it's what I
have to transform now. I want to build a transformation that can handle
this level of complexity and higher from the input model and, of course, a
lower level of complexity as the one you mentioned. The issue of unique
identification of of metamodel elements (see my email below and the screen
capture attached) is capital when having multiple type of components. I
really need to know if GREAT can handle this and how. I’ll also welcome any
workaround strategy.

Thanks,

Leonard

2012/3/8 Joe Porter <joe.porter at gmail.com>

> 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
> >
> _______________________________________________
> 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/20120312/e0c484ac/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sample Model.pdf
Type: application/pdf
Size: 44946 bytes
Desc: not available
Url : http://list.isis.vanderbilt.edu/pipermail/great-users/attachments/20120312/e0c484ac/attachment.pdf 