Eclipse Community Forums: UML2 » Class templates and associations

Help

Home

Home » Modeling » UML2 » Class templates and associations

Show: Today's Messages :: Show Polls :: Message Navigator

Class templates and associations [message #478564]

Mon, 29 June 2009 14:23

Carsten Reckord

Messages: 139
Registered: July 2009

Senior Member

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?

2) For the type bounds "X extends Foo", ignoring that the converter uses an EMF-specific stereotype instead of constrainingClassifier, what
is the benefit of introducing the additional constrainingClassifier property at all, instead of just defining a Generalization from the
parameter class X to Foo?

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(...)?

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

Report message to a moderator

Re: Class templates and associations [message #478569 is a reply to message #478564]

Tue, 30 June 2009 20:10

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Carsten,

While I'm making my way through your questions, you may want to have a look
at:
http://www.eclipse.org/modeling/mdt/uml2/docs/articles/Defin ing_Generics_with_UML_Templates/article.html

Cheers,
- James.

"Carsten Reckord" <creckord@uni-kassel.de> wrote in message
news:h2aiq0$os4$1@build.eclipse.org...
> 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?
>
> 2) For the type bounds "X extends Foo", ignoring that the converter uses
> an EMF-specific stereotype instead of constrainingClassifier, what is the
> benefit of introducing the additional constrainingClassifier property at
> all, instead of just defining a Generalization from the parameter class X
> to Foo?
>
> 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(...)?
>
> 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

Report message to a moderator

Re: Class templates and associations [message #478594 is a reply to message #478564]

Tue, 07 July 2009 14:08

james bruck

Messages: 1724
Registered: July 2009

Senior Member

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@uni-kassel.de> wrote in message
news:h2aiq0$os4$1@build.eclipse.org...
> 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

Report message to a moderator