Eclipse Community Forums: UML2

Help

Home

Home » Modeling » UML2 » Association ends

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

Association ends [message #472095]

Fri, 30 March 2007 16:22

Lutz Wrage

Messages: 181
Registered: July 2009

Senior Member

The eclipse implementation of associations seems to violate a subset
constraint in the UML 2.1.1 spec: Property Association::memberEnd must
be a subset of Namespace::member.

But then it seems that this constraint doesn't make a lot of sense
because it would require all end properties to be owned by associations.
However, the spec talks about association end properties owned by
classifiers and even introduces the dot notation for it...

However, I couldn't find an issue raised against the spec, so maybe
there's an error in my interpretation?

- Lutz

Report message to a moderator

Re: Association ends [message #472100 is a reply to message #472095]

Mon, 02 April 2007 06:44

Dennis Wagelaar

Messages: 147
Registered: July 2009

Senior Member

Lutz Wrage schreef:
> The eclipse implementation of associations seems to violate a subset
> constraint in the UML 2.1.1 spec: Property Association::memberEnd must
> be a subset of Namespace::member.

That seems to be fine: both Association::memberEnd and Namespace::member
are not referring to "owned" elements. The elements only need to be
uniquely identifiable within the Namespace. That means that Property
elements owned by a Classifier can still be part of Association::memberEnd.

Association::ownedEnd and Namespace::ownedMember on the other hand *do*
refer to "owned" elements.

Can you verify this, Lutz?

--
Regards,
Dennis

>
> But then it seems that this constraint doesn't make a lot of sense
> because it would require all end properties to be owned by associations.
> However, the spec talks about association end properties owned by
> classifiers and even introduces the dot notation for it...
>
> However, I couldn't find an issue raised against the spec, so maybe
> there's an error in my interpretation?
>
> - Lutz

Report message to a moderator

Re: Association ends [message #472102 is a reply to message #472100]

Mon, 02 April 2007 13:21

Lutz Wrage

Messages: 181
Registered: July 2009

Senior Member

Dennis Wagelaar wrote, on 4/2/2007 2:44 AM:
> Lutz Wrage schreef:
>> The eclipse implementation of associations seems to violate a subset
>> constraint in the UML 2.1.1 spec: Property Association::memberEnd must
>> be a subset of Namespace::member.
>
> That seems to be fine: both Association::memberEnd and Namespace::member
> are not referring to "owned" elements. The elements only need to be
> uniquely identifiable within the Namespace. That means that Property
> elements owned by a Classifier can still be part of Association::memberEnd.
>
> Association::ownedEnd and Namespace::ownedMember on the other hand *do*
> refer to "owned" elements.
>
> Can you verify this, Lutz?

I agree. However, the definition of Namespace::member states that
members are either owned, inherited, or imported. An association end
property that is owned by a classifier is an ownedMember of that
namespace. The property is not imported into the association's
namespace, because that would require an element import or package
import somewhere. The property is also not inherited by the association
because the association does not generalize the classifiers at it's
ends. So I don't see a way in the spec to make the end property a
memberEnd of the association.

Let's assume for the moment that the description of Namespace::member is
incomplete because it doesn't list other ways of introducing a member
into a namespace, and that all association end properties are indeed
members of the association's namespace. What if both end properties are
now owned by the respective classifiers but have the same name? That's
fine because they are in different classifier namespaces, but they are
not distinguishable in the association's namespace. That's according to
my interpretation of the opertation NamedElement::isDistinguishableFrom.
(It's definition uses an attribute oclType which doesn't seem to be
valid OCL. It's getting more and more frustrating to read these specs :(

- Lutz

>
> --
> Regards,
> Dennis
>
>>
>> But then it seems that this constraint doesn't make a lot of sense
>> because it would require all end properties to be owned by
>> associations. However, the spec talks about association end properties
>> owned by classifiers and even introduces the dot notation for it...
>>
>> However, I couldn't find an issue raised against the spec, so maybe
>> there's an error in my interpretation?
>>
>> - Lutz
>

Report message to a moderator

Re: Association ends [message #472218 is a reply to message #472102]

Tue, 03 April 2007 20:12

Kenn Hussey

Messages: 1620
Registered: July 2009

Senior Member

Lutz,

Yes, I suppose you could say that the description of Namespace::member is
"incomplete" from that perspective... the bottom line is that the members of
a namespace (a derived union) include anything that is contributed via a
subsetting property.

It would seem invalid for more than one member end of an assocation to have
the same name, so I think this restriction is a good thing.

Kenn

"Lutz Wrage" <lw_mailme_00@yahoo.com> wrote in message
news:eur00o$9gs$1@build.eclipse.org...
> Dennis Wagelaar wrote, on 4/2/2007 2:44 AM:
>> Lutz Wrage schreef:
>>> The eclipse implementation of associations seems to violate a subset
>>> constraint in the UML 2.1.1 spec: Property Association::memberEnd must
>>> be a subset of Namespace::member.
>>
>> That seems to be fine: both Association::memberEnd and Namespace::member
>> are not referring to "owned" elements. The elements only need to be
>> uniquely identifiable within the Namespace. That means that Property
>> elements owned by a Classifier can still be part of
>> Association::memberEnd.
>>
>> Association::ownedEnd and Namespace::ownedMember on the other hand *do*
>> refer to "owned" elements.
>>
>> Can you verify this, Lutz?
>
> I agree. However, the definition of Namespace::member states that members
> are either owned, inherited, or imported. An association end property that
> is owned by a classifier is an ownedMember of that namespace. The property
> is not imported into the association's namespace, because that would
> require an element import or package import somewhere. The property is
> also not inherited by the association because the association does not
> generalize the classifiers at it's ends. So I don't see a way in the spec
> to make the end property a memberEnd of the association.
>
> Let's assume for the moment that the description of Namespace::member is
> incomplete because it doesn't list other ways of introducing a member into
> a namespace, and that all association end properties are indeed members of
> the association's namespace. What if both end properties are now owned by
> the respective classifiers but have the same name? That's fine because
> they are in different classifier namespaces, but they are not
> distinguishable in the association's namespace. That's according to my
> interpretation of the opertation NamedElement::isDistinguishableFrom.
> (It's definition uses an attribute oclType which doesn't seem to be valid
> OCL. It's getting more and more frustrating to read these specs :(
>
> - Lutz
>
>>
>> --
>> Regards,
>> Dennis
>>
>>>
>>> But then it seems that this constraint doesn't make a lot of sense
>>> because it would require all end properties to be owned by associations.
>>> However, the spec talks about association end properties owned by
>>> classifiers and even introduces the dot notation for it...
>>>
>>> However, I couldn't find an issue raised against the spec, so maybe
>>> there's an error in my interpretation?
>>>
>>> - Lutz
>>

Report message to a moderator

Re: Association ends [message #472219 is a reply to message #472218]

Tue, 03 April 2007 20:44

Lutz Wrage

Messages: 181
Registered: July 2009

Senior Member

I've read some more through the spec regarding namespaces and checking
for name conflicts. The result is that members of a namespace that are
neither owned by the namespace, nor imported, nor inherited can have any
name they want. They are always distinguishable from all other names
because the ocl Namespace::getNamesOfMember() always returns the empty
set for these members.

Consequently ends of an association _can_ have identical names, if it's
a binary association and at most one end is owned by the association. If
both ends are owned by the association, then their names must be
different. I've verified that the eclipse UML2 implementation behaves
like this.

It turns out that everything works somehow, but it would be interesting
to know if this is by design or by accident. ;-)

I still find it a bit strange that a namespace can have members that
don't have a name in that namespace...

- Lutz

Kenn Hussey wrote, on 4/3/2007 4:12 PM:
> Lutz,
>
> Yes, I suppose you could say that the description of Namespace::member is
> "incomplete" from that perspective... the bottom line is that the members of
> a namespace (a derived union) include anything that is contributed via a
> subsetting property.
>
> It would seem invalid for more than one member end of an assocation to have
> the same name, so I think this restriction is a good thing.
>
> Kenn
>
> "Lutz Wrage" <lw_mailme_00@yahoo.com> wrote in message
> news:eur00o$9gs$1@build.eclipse.org...
>> Dennis Wagelaar wrote, on 4/2/2007 2:44 AM:
>>> Lutz Wrage schreef:
>>>> The eclipse implementation of associations seems to violate a subset
>>>> constraint in the UML 2.1.1 spec: Property Association::memberEnd must
>>>> be a subset of Namespace::member.
>>> That seems to be fine: both Association::memberEnd and Namespace::member
>>> are not referring to "owned" elements. The elements only need to be
>>> uniquely identifiable within the Namespace. That means that Property
>>> elements owned by a Classifier can still be part of
>>> Association::memberEnd.
>>>
>>> Association::ownedEnd and Namespace::ownedMember on the other hand *do*
>>> refer to "owned" elements.
>>>
>>> Can you verify this, Lutz?
>> I agree. However, the definition of Namespace::member states that members
>> are either owned, inherited, or imported. An association end property that
>> is owned by a classifier is an ownedMember of that namespace. The property
>> is not imported into the association's namespace, because that would
>> require an element import or package import somewhere. The property is
>> also not inherited by the association because the association does not
>> generalize the classifiers at it's ends. So I don't see a way in the spec
>> to make the end property a memberEnd of the association.
>>
>> Let's assume for the moment that the description of Namespace::member is
>> incomplete because it doesn't list other ways of introducing a member into
>> a namespace, and that all association end properties are indeed members of
>> the association's namespace. What if both end properties are now owned by
>> the respective classifiers but have the same name? That's fine because
>> they are in different classifier namespaces, but they are not
>> distinguishable in the association's namespace. That's according to my
>> interpretation of the opertation NamedElement::isDistinguishableFrom.
>> (It's definition uses an attribute oclType which doesn't seem to be valid
>> OCL. It's getting more and more frustrating to read these specs :(
>>
>> - Lutz
>>
>>> --
>>> Regards,
>>> Dennis
>>>
>>>> But then it seems that this constraint doesn't make a lot of sense
>>>> because it would require all end properties to be owned by associations.
>>>> However, the spec talks about association end properties owned by
>>>> classifiers and even introduces the dot notation for it...
>>>>
>>>> However, I couldn't find an issue raised against the spec, so maybe
>>>> there's an error in my interpretation?
>>>>
>>>> - Lutz
>
>

Report message to a moderator