C++ template instantiation

[edroi]

Hi

I am trying to use Enterprise Architect for documenting and modeling C++ projects.
So far I've been quite happy with the tool. However I have a couple of issues I'd like to be resolved.
Can anybody explain me how to create an instantiation of a parametrized class (C++ template)?
In Rational Rose a result of instantiation of a template class would look like an anonymous class (with stereotype "anonymous") with a specific template parameter. This class will be connected to the parametrized one with association 'instantiates'. (The same is created as a result of reverse engineering.)
The only help I found in EA regarding this subject is in the topic about parametrized classes where it is said
"For an instantiated template, select Instantiated and add the arguments in the Arguments field"
I tried that and didn't really see on the UML diagram any difference between regular classes and instantiated one.
Am I missing anything?

Thanks
Eugene

[Makulik]

Hi,

There's no difference shown for instantiations of parameterized classes vs. regular ones in EA.
In short:
Generalize the parameterized class from a new one, name it appropriately (e.g. provide the full language syntax like 'map<string>'), provide the same class parameters as in the base, also fill in the Arguments, and set 'none' as code generation language.

HTH
Günther

[edroi]

Thanks Gunter.
However I am a bit puzzled what's really value there in specifying those arguments.
Besides in my view it would make more sense having the relationship with a template class 'instantiate' vs 'generalize".
Also naming a class "map<string>" does not look semantically  correct to me. It is probably good enough though for presentation purposes

[Makulik]

Besides in my view it would make more sense having the relationship with a template class 'instantiate' vs 'generalize".

In fact it should be a <<bind>> stereotyped dependency AFAIK, but this is not really supported by EA.

Also naming a class "map<string>" does not look semantically  correct to me. It is probably good enough though for presentation purposes

Not so sure now if this is necessary at all. But filling in the Arguments field matters for code generation (e.g. if a class inherits an instantiated parameterized class).

I have a more detailed article (tutorial) about this topic. If you're interested, leave your eMail in my message box and I'll hand it out to you.

WBR
Günther

[edroi]

Thanks
I sent my email to you.
Please let me know in case you didn't receive it

[g.makulik]

Hi Eugene,

Yes, after having a look again, I'm using the notation I have mentioned in my last post. At least it's valid UML notation (you can name classes as you like) and helps with correct (C++)code generation from EA.
The UML 2.2 Superstructure spec (http://www.omg.org/spec/UML/2.2/Superstructure/PDF/)
covers the topic in chapter '17.5 Templates' (couldn't really find this so quickly ;-)).
It's the <<bind>> dependency stereotype that should be used for instantiations (substitutions) of parametrized classes. As described there further, the notation to specify the substituted class parameters is to put text label (the <<bind>> associations name?) besides the stereotype, like this for given class parameters T:class, k:int :

    <<[size=9]bind[/size]>>[size=9] <T -> S1, k -> 5>[/size]

At least this could be visualized easily in EA using the associations name. But this will have no impact
on code generatioon AFAIK.

WBR
Günther

[Paolo F Cantoni]

[size=18]...[/size]
The UML 2.2 Superstructure spec (http://www.omg.org/spec/UML/2.2/Superstructure/PDF/)
covers the topic in chapter '17.5 Templates' (couldn't really find this so quickly ;-)).
It's the <<bind>> dependency stereotype that should be used for instantiations (substitutions) of parameterized classes.
[size=18]...[/size]

Hi Gunther,

I believe the «bind» relationship, together with «realization» and «generalization» are examples of transformative relationships.  Where the instructions for the transform should be contained in the relationship, not the end items.  Unfortunately (AFAIK), no tools take this view and so they all struggle.

If one did take this view, one could even provide «transform» relationships (dependency) that would identify the origins and destinations of transforms.

Just my  AU$0.05,
Paolo