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

[Joe Porter]

Leonard,

This is not a problem - GReAT is great for this sort of thing (sorry
for the bad pun).  Here is what I would do in the transformation:

Rule M: Visit all of the ModPart objects, match one ModPin connected
as source to a Connect object and create an OutFlowPort in the target
model.  Translate attributes and create a CrossLink from the ModPin
object to the newly created target model Port.  The CrossLink must be
defined between a ModPort and an OutFlowPort.
Rule N: Do the same, but match ModPin connected as destination to a
Connect object.  Create an InFlowPort and a cross link from the ModPin
to the InFlowPort.
Rule O: Visit all of the ModPart objects, match ModInFlow and create
the right kind of Port in the target model.  Translate attributes and
create a CrossLink.
Rule P: Do the same for ModPart, ModOutFlow.
Rule Q: Do the same for ModBlock, ModInFlow.
Rule R: Do the same for ModBlock, ModOutFlow.

It will be easiest to specify that GReAT handle all of these rules in
parallel.  Just fan out the connections from the output ports of the
previous rule to all of the input ports of these rules.

Once you have the ports created and the CrossLinks, it's time to
create the connections.  You will need one rule for each type of
connection you need to create in the target model.

Rule S: Match the Connect type and the ports it attaches to, along
with the CrossLinked ports in the target model.  Create the
corresponding FlowSpecification connection in the target model between
the CrossLinked target ports.  Add a guard to make sure you create
FlowSpecification for the right things.  Make sure the new
FlowSpecification is a child of the proper SysMLBDD object.

You can aggregate the output ports from all of the Rules M-R into the
input ports of rule S. That should create the whole model you showed
in the example.

Note that if you have nothing connected to a ModPin, it will be
impossible to tell whether to create the corresponding target port as
InFlowPort or OutFlowPort unless you have more data somewhere.

If you have problems with any of that then we may need to expand some
of the base types, but I think it will work as expected.  The usual
disclaimers apply about missing important details.  You may have to
adapt a few of the steps as you get into it.  The problem with free
help is that you can't get your money back if it's no good ;-)

-Joe

2012/3/12 Léonard PETNGA <lpetnga at gmail.com>:
> 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
>
>
>