TemplateBinding error on model transformation

[Gusztav]

 :'(Hi,

I'm trying to transform a domain model to C# class model. The domain modelt contains some template classes and some classes subtituting the template parameter with a concretet type. Say the template class is TC<T> and the concrete one is CC. in this case I use a bind connector pointing from CC to TC, and in the Bindings panel, T is substituted with a type (sometime with a simple type like int, sometimes with classes). The diagram showing these classes shows UML-compliant.

The transformation, however, does not succeed. EA drops the following message:

There was an error parsing C:\<path> on line 1916.
Unexpected symbol: TemplateBinding

Taking a look at the log file, line 1916 contains "TemplateBinding", the intermediary definition of a template binding. This is the first template binding in the file.

I have no clue what may be wrong, since there is no additional information I'm aware of. Did any of you run into the same problem, and can you tell me a solution or workaround other than avoid using template classes in the domain model?

Gus

[Gusztav]

For those interested in the answer, we have tracked down the problem. Our conclusions, confirmed by support are the followings:

• MDA does not support templatebinding connectors, nor abstraction connectors. Trying to transform a package with such connectors, and the MDA transformer will find the TemplateBinding or the Abstraction element unexpected. This is way not ideal, since the normal way of modeling template binding is the dedicated Template Binding connector. Abstraction, on the other hand, became the result of trace dependencies between classes: again, it was great to leave us the opportunity to informally link classes with trace connectors without causing MDA errors. But forget about abstraction and trace for now.
• Model transformation works when eliminating all Template Binding connectors and replacing them with generalizations, with the required parameter substitutions specified on the Generalization connector.
• Templates and parameters are, however, not transformed: if you have two classes, a template Foo<T> another called Bar subsituting T in Foo with int (that is: B: Foo<int>), you’d expect the same structures in the C# model. Unfortunatelly, however, the template class loses its parameter and the subclass loses its param subsitution and the C# model will end up in two plain classes: Foo and Bar: Foo.
• Naturally, when generating code from the C# model, you won’t have any templated classes in source code files.
• The only way to create source code files with correct template parameters and substitutions is to generate code from the original class model: but in this case common UML types won’t be converted to C# types and you loose all other benefits the C# MDA transformation would add.

What we could come up with is to have the name of the template parameter of generic classes transformed by MDA by adding a ClassParameter template to the set of MDA templates, but we could not access the type, constraint and default attribute of generic parameters, neither could we access parameter substitution data in classes derived from the generic and substituting the generic parameter with a concrete type.

[Stephane B]

Yep, I asked a similar(ly unanswered) question. Thanks for the Generalization tip ; missed it.
If I understand well, you are doing a two-step PIM to C#Specific Model to C# code. In this case, there could be a hacky solution to get your substitution parameter back:

1st, you tune the PIM to C#model transformation to put the value of your substitution parameter in a particular tagged value, say "ParameterSubstitution".

2nd, you tune the C# code template so that when it encounters such tagged value, it outputs "<"+%Tag:ParameterSubstitution%+">".

Did something resembling with imports. Should work. Let us know.

Stéphane

[Gusztav]

Hi Stéphane,

Thanks for the tip! We also managed to invent this option and could get our transformation to work. Actually the problem with tagged values shadowing some other fields is that, as to my eyes, that you practically do not have any means to keep them sync'd, just as if you were entering List<Foo>, for example, for the return type of a method: renaming foo won't have an effect on the type. Do you have any suggestions for keeping these information in sync? I'd pleased to get some hints.

Cheers,
Gus