Model transforms: share data between templates?

[PeterKeller]

I cannot see how to share data between templates in different contexts, for example between Namespace and Connector templates. Templates of type <None> can take parameters, but can't be used in a list macro or to change context. Typed templates can't take parameters at all, as far as I can see.

Have I missed something obvious? Has anyone else faced this problem and found an approach that works? Or am I barking up the wrong tree completely?

Thanks for any hints,
Peter.

[Eve]

Anything you can calculate in the top level template, can also be calculated at a lower level template.  (Actually, the exception to this is for inner classes.)

It is duplication, but it should get you by.

[PeterKeller]

Anything you can calculate in the top level template, can also be calculated at a lower level template.

Thanks for the reply. I tried it that way around too, but the thing that I couldn't get to work is getting back up to a higher-level context from a template at a lower context. For example, this construction in a Class template:

Code: [Select]

%list="Namespace__MyTemplate"%
produces nothing in the intermediary file, presumably because Namespaces contain Classes, not the other way around. Is there some way of telling the %list% macro to start from the package that is being transformed, rather than the current context?

[PeterKeller]

No comments anyone? I'll be a bit more specific about what I am trying to do in the hope that someone can suggest a working approach. I need to create a new connector between two classes (rather than transform an existing one). The two classes could be in different packages. When I am in the context of one of the classes, I can't figure out how to get at the GUID of the other one.

Maybe there is another way of doing this completely? Can the two connector ends be created separately, something like this:

Code: [Select]

Generalisation {
 ... some reference ...
  Target {
      XRef{ .... }
     ...
  }
}
Generalisation {
  ... something to identify this connector with the previous one ...
  Source {
      XRef{...}
      ...
  }
}

I am aware that creating new elements like this means that synchronisation won't work (i.e. I will have to wipe the generated model and re-create it each time), but I am OK with that.

Regards,
Peter.

[Eve]

How are you identifying what relationships need to be created?

There needs to be some relationship between the two classes.  A transformation should never make one up for itself.

You could have a RefGUID type tagged value.  In which case you can use it's value to generate the connector reference.

You could have a connector of another kind (maybe stereotyped) so that you can identify it.

But if you don't have anything.  You need to rethink what you are doing, because you are attempting to encode your model information into your transformation.  It's the wrong place to put that information.

[PeterKeller]

How are you identifying what relationships need to be created?

Good question. In the transformed model (which is a PIM of course) I want to make one particular class the parent of every other class that does not already have a parent. This generalisation is only meaningful in the particular physical implementation model that I am transforming into, so I don't want to put it in the source model.

There needs to be some relationship between the two classes.  A transformation should never make one up for itself.

You could have a RefGUID type tagged value.  In which case you can use it's value to generate the connector reference.

There are any number of ways that I could flag this parent class (tagged value, dependency relationship between relevant packages and this class, etc. etc.). I don't have a strong feeling about how to do it, as long as I don't have to explicitly flag every class that will become a child of the parent class. I just can't find a way of finding the parent class in a class template that is transforming a child class, or alternatively doing a %list% operation over the child classes in the context of the parent class. At the moment, the GUID of the parent class is hard-coded in the template itself. That works, but offends my sense of tidiness  

You could have a connector of another kind (maybe stereotyped) so that you can identify it.

But if you don't have anything.  You need to rethink what you are doing, because you are attempting to encode your model information into your transformation.  It's the wrong place to put that information.

All good points. These extra generalisations come from the requirement to incorporate a package from another model into mine, and arise purely from the requirements of the physical implementation, which I don't have much control over. This is why I don't want to add the generalisations to the source model. If it wasn't for this "third party" aspect, I would probably come up with a different approach.

[Eve]

So, the situation is that there is an implicit relationship whenever no explicit relationship exists.

That is a little hard to do, it's not a situation I had considered.  But you should be able to do it with a few custom templates (roughly) as follows.

File

Code: [Select]

$implicit=%list="Namespace__Implicit" @separator="\n"%
$parent=%list="Namespace__ImplicitParent" @separator="\n"%
%REPLACE($implicit, "#IMPLICIT_PARENT#", $parent)%
Namespace__Implicit

Code: [Select]

%list="Namespace__Implicit" @separator="\n\n" @indent=""%
%list="Class__Implicit" @separator="\n\n" @indent=""%
Class__Implicit

Code: [Select]

$test=%list="ClassBase" @separator="\n" @indent="  "%
%if $test != ""%
%endTemplate%

Generalisation {
%TRANSFORM_REFERENCE("Implicit",classGUID)%
 Source {
     %TRANSFORM_REFERENCE("Class",classGUID)%
 }
Target
{
     %TRANSFORM_REFERENCE("Class","#IMPLICIT_PARENT#")%
}
}
Namespace__ImplicitParent

Code: [Select]

%list="Namespace__ImplicitParent" @separator="\n\n" @indent=""%
%list="Class__ImplicitParent" @separator="\n\n" @indent=""%
Class__ImplicitParent

Code: [Select]

%if classStereotype=="implicitparent"%
%classGUID%
%endIf%
I hope you get the idea.

[PeterKeller]

So, the situation is that there is an implicit relationship whenever no explicit relationship exists.

That is a little hard to do, it's not a situation I had considered.  But you should be able to do it with a few custom templates (roughly) as follows.

... snip ...

I hope you get the idea.

With an additional check so that I don't create a generalisation from the implicit parent to itself, this works fine.

Many thanks for your help!