[news.eclipse.modeling.mdt.uml2] Re: Class templates and associations

["James Bruck" <jbruck@xxxxxxxxxx>]

Some of the questions responded to below ... I will respond to the rest a 
bit later when I get a chance.
Cheers,
-James.

"Carsten Reckord" <creckord@xxxxxxxxxxxxx> wrote in message 
news:h2aiq0$os4$1@xxxxxxxxxxxxxxxxxxxx
> Hi,
>
> After bashing my head against UML templates for a while, I came across the 
> tip of using the more familiar (for Java folks) EMF generics and looking 
> what the EMF to UML converter makes of it. While that helped a lot, I 
> still have a couple of questions I couldn't solve for myself that way and 
> a couple of questions/comments about what the Converter generates.
>
> I) Let's start with class templates in general. Say I have the following 
> (in Java-like pseudo-notation):
>
> class Foo;
> class Bar<X extends Foo>
> {
>    void doStuff ();
>    <Y extends Foo> Y calculate(Bar<Y> otherBar);
> }
>
> Using the EMF to UML converter I get the following UML model:
>
> class Foo;
> class Bar
>    TemplateSignature
>       Classifier Template Parameter X
>          Class X
>    operation doStuff ()
>       (Return Parameter)
>
>    class Bar_Y
>       Template Binding Bar<X->Y>
>
>    operation calculate(Bar_Y otherBar): Y
>       TemplateSignature
>          Classifier Template Parameter Y
>             Class Y
>
> 1) Not actually template related, but instead of a return parameter 
> without a type, shouldn't the doStuff method have no return parameter at 
> all if the Ecore method did not have a return type?

Yes possibly, I believe this is a by-product of how we try to manufacture 
types during the conversion process.  Either way I don't think it should 
cause a problem.  If it is a problem please raise a bugzilla.

>
> 2) For the type bounds "X extends Foo", ignoring that the converter uses 
> an EMF-specific stereotype instead of constrainingClassifier, what
The stereotype is used since there is an issue in the spec where you can't 
express X extends Foo & Bar & ...  I believe you are restricted to 1 item. 
We use the stereotype for consistency.

> is the benefit of introducing the additional constrainingClassifier 
> property at all, instead of just defining a Generalization from the 
> parameter class X to Foo?
X might not directly extend Foo so creation a generalization may not be 
appropriate.  I believe we are correctly using the constraining classifier 
the way it is intended by the spec.


>
> 3) The bound class Bar_Y is generated in Bar, obviously because an 
> Operation is not a Namespace and cannot contain a Class. But strictly 
> speaking, isn't the template parameter Y, used as actual parameter in the 
> binding of Bar_Y, out of scope at this point since the binding does not 
> happen inside of calculate(...)?

I haven't reproduced your example but assuming that your example above is 
correct, you may have a point here.   I will have to look at this in more 
detail.    Please raise a bugzilla.


--------------------------  part 2 a bit later ----------------------

>
> 4) It can easily happen that I get multiple "synthetic" classes 
> Bar_something binding Bar to the same actual parameters (i.e. in 2 
> different packages and then seeing both types in a package that imports 
> both). Is there any specification available about if/when such classes 
> should be considered compatible with each other?
>
>
>
> II) Now for a slightly more complex example involving associations:
>
> class Foo<X>
> {
>    Bar<X> bar;//otherEnd=Bar.foo
> }
>
> class Bar<Y>
> {
>    Foo<Y> foo;//otherEnd=Foo.bar
> }
>
> class StringFoo extends Foo<String>;
> class StringBar extends Bar<String>;
>
> So I basically have an association between two templates with the 
> respective other side's parameter bound to my own. The abridged version in 
> UML looks like this:
>
> class Foo<X>
>    class Bar_X (Bar<Y->X>)
>    property bar : Bar_X
>
> class Bar<Y>
>    class Foo_Y (Foo<X->Y>)
>    property foo : Foo_X
>
> association A_Foo_Bar
>    memberEnd Foo.bar, Bar.foo
>
> class Foo_String (Foo<X->String>)
> class Bar_String (Bar<Y->String>)
>
> class StringFoo
>    generalization Foo_String
> class StringBar
>    generalization Bar_String
>
>
> According to the Superstructure specification, the semantics of this 
> should be the same as if the template contents were copied into the 
> binding classes and the parameters replaced accordingly. However, 
> attempting to manually perform such a copy operation on my example model 
> for Foo_String and Bar_String, I run into a couple of problems:
>
> 1) In a way, this is related to question I.4: Copying the contents of 
> Foo<X> into Foo_String would entail copying the nested class Bar_X as 
> well. Then I would need to "merge" Bar_X which in turn would add an inner 
> class Foo_Y to it, which in turn... StackOverflow... Of course in reality 
> I probably shouldn't perform this copying ad infinitum, but recognize that 
> Bar_X should be equivalent to Bar_String under the current binding. But 
> how would I recognize that in general?
>
> 2) Strictly speaking, the association A_Foo_Bar is not part of either of 
> the two template classes. But if I copy all contents of the templates into 
> the binding classes "as is", i.e. with 
> Foo_String.bar.association=A_Foo_Bar, I'd end up with a 4-ary association. 
> Obviously, A_Foo_Bar also needs to be copied (into the namespace of 
> Foo_String?). But how would I recognize in general what to copy (and where 
> to) and what not? Would this always be every element that is either 
> contained in a template itself or references something contained in a 
> template?
>
> 3) Changing the association into a uni-directional reference Foo.bar in 
> EMF results in a UML association with an ownedEnd of type Foo (without 
> binding). Shouldn't that be Foo_X, with Foo_X being an inner class of Foo 
> with binding Foo<X->X>?
>
>
> As you can see by this soewhat longish post, I think that the template 
> binding semantics section of the Superstructure could use a bit of 
> clarification ;P Meanwhile I'd greatly appreciate any help with any of 
> these questions or any pointers to material beside the Superstructure spec 
> that sheds some light on this topic.
>
>
> Best regards,
> Carsten Reckord