Home » Modeling » UML2 » Navigability Semantics of Associations
| Navigability Semantics of Associations [message #476846] |
Sat, 12 January 2008 08:05  |
Eclipse User |
|
|
|
Hello,
I try to understand the navigability semantics of associations.
Because I am very insure if my below statements are correct, please
correct them if neccessary:
Suppose I have a Class Book and a Class Author.
Task 1 - Bidirectional Navigability:
------------------------------------
I'd like to have an association book_author between the two
Classes which is navigable in both directions:
a. Create an Association book_author.
b. Inside the Author class I create an owned Property "books" of type
Book set its Association Property to "book_author"
c. Inside the Book class I create an owned Property "author" of type
Author and also set its Association Property to "book_author".
Task 2 - Unidirectional Navigability
-------------------------------------
I'd like to restrict navigability, only Author->Book should be
possible.
a. I change the owner of the "author" property from Book to the
Association "book_author".
Conclusion: Since the "author" end is now owned by the Association
it is not navigable from the opposite end "book" anymore.
Task 3 - Restore Navigability by making Use of an Association's
"navigableOwnedEnd" property:
------------------------------------------------------------ ----
If I also add the "author" end to the "ownedNavigableEnds"
property of the Association, navigation from "book" to "author" would
be possible again.
Now I can't see any semantic difference between an end owned by an
opposite end's class and that end owned by the Association and part of
its "ownedNavigableEnd" property. Do I miss something?
Task 4 - Make the Association not navigable at all
--------------------------------------------------
Make all ends owned by the Association. Why should one need this?
Thanks for a discussion.
Felix
|
|
|
| Re: Navigability Semantics of Associations [message #476850 is a reply to message #476846] |
Mon, 14 January 2008 11:38  |
| Eclipse User |
|
|
|
Hi Felix,
Navigability and end ownership are two distinct notions in UML. Prior to
UML 2.0 the two concepts were not separated out. For example, if the end
was not owned by the classifier at the end then you could not navigate to
the other end. This however has changed.
Have a look at http://www.omg.org/cgi-bin/doc?formal/07-02-05, section 7.5
or http://www.omg.org/issues/uml2-superstructure-ftf.html#Issue 8956 .
There is new notation for this ( the dot at the end ).
It is possible to have the association own its ends and still be able to
navigate from one end to the other. This might be useful if you have some
hash table that gets dynamically populated at runtime. The table would
represent an association between two classes say, 'A' and 'B'. 'A' might
not have any property of type 'B' but at runtime, by virtue of looking it up
in the table, we can navigate to 'B', given 'A'.
In this case, we have an association between 'A' and 'B' and we can navigate
between them even though neither 'A' nor 'B' owns the end.
Cheers,
- James.
"Felix Dorner" <felix_do@web.de> wrote in message
news:20080112140505.33a78634@serenity...
> Hello,
>
> I try to understand the navigability semantics of associations.
> Because I am very insure if my below statements are correct, please
> correct them if neccessary:
>
> Suppose I have a Class Book and a Class Author.
>
> Task 1 - Bidirectional Navigability:
> ------------------------------------
>
> I'd like to have an association book_author between the two
> Classes which is navigable in both directions:
>
> a. Create an Association book_author.
>
> b. Inside the Author class I create an owned Property "books" of type
> Book set its Association Property to "book_author"
>
> c. Inside the Book class I create an owned Property "author" of type
> Author and also set its Association Property to "book_author".
>
>
> Task 2 - Unidirectional Navigability
> -------------------------------------
>
> I'd like to restrict navigability, only Author->Book should be
> possible.
>
> a. I change the owner of the "author" property from Book to the
> Association "book_author".
>
> Conclusion: Since the "author" end is now owned by the Association
> it is not navigable from the opposite end "book" anymore.
>
>
> Task 3 - Restore Navigability by making Use of an Association's
> "navigableOwnedEnd" property:
> ------------------------------------------------------------ ----
>
> If I also add the "author" end to the "ownedNavigableEnds"
> property of the Association, navigation from "book" to "author" would
> be possible again.
>
> Now I can't see any semantic difference between an end owned by an
> opposite end's class and that end owned by the Association and part of
> its "ownedNavigableEnd" property. Do I miss something?
>
> Task 4 - Make the Association not navigable at all
> --------------------------------------------------
>
> Make all ends owned by the Association. Why should one need this?
>
>
>
> Thanks for a discussion.
> Felix
|
|
| |
| Re: Navigability Semantics of Associations [message #476866 is a reply to message #476863] |
Tue, 22 January 2008 10:06 |
| Eclipse User |
|
|
|
Felix,
I don't agree that there is a contradiction here.
The dot next to A indicates that B owns the "A" end of the assocation (not
the other way around) - remember that the notational attributes of an
association end are displayed on the end of the relationship line that's
opposite from its owner (I know, it's not necessarily intuitive)...
Kenn
"Felix Dorner" <felix_do@web.de> wrote in message
news:20080119214621.44908fbe@serenity...
>
> Hey James,
>
>
> I am looking at the Superstructure 2.1.1 Spec and come up with the
> following issue:
>
> On Page 39 in the Description Section of "Association":
> "An end property of an association that is owned by an end class [...]
> indicates that the association is navigable from the opposite ends
> [...]"
>
> On Page 42 they explain the ownership "Dot" notation which is
> illustrated on the next page by some Examples. To me the first example
> of Figure 7.20 is a contradiction to the above citation:
>
> The dot next to A indicates that A owns the "B" end of the Association.
> According to the citation, this indicates that one can navigate from A
> to B. However, the "B" end is indicated "non navigable" by the
> "x" notation.
>
> I see a clear contradiction here.
>
> Further, on Page 43, "[...] navigability and end
> ownership are orthogonal concepts each with their own explicit
> notation". The example fully makes use of this statement,
> but I just can't see how to model the mentioned example, i.e. an
> owned association end which is not navigable.
>
>
> Felix
|
|
| | | | | |
| Re: Navigability Semantics of Associations [message #476950 is a reply to message #476875] |
Mon, 18 February 2008 12:42 |
| Eclipse User |
|
|
|
hi kenn,
this means that
createAssociation(clazz, true, AggregationKind.COMPOSITE_LITERAL,
"name1", 1, 1, clazz2, false, AggregationKind.NONE_LITERAL, "name2", 1,
1); //from the uml getting started example
results in the 'correct' model?
-stefan
Kenn Hussey wrote:
> Believe me, I know the feeling. ;)
>
> Kenn
>
> "Felix Dorner" <felix_do@web.de> wrote in message
> news:fn5ejr$5u7$1@build.eclipse.org...
>> Phew.. It's really great to have this list to discuss UML. I imagine just
>> me and the 900 pages of specification... This really teaches one to not be
>> awestruck by it but to discuss and question fishy-lookin concerns.
>>
>> Thanks,
>> Felix
>>
>> Kenn Hussey wrote:
>>> Ah, I see it now - you are right! It should be invalid for both the
>>> non-navigability (x) and the ownership (dot) notations to appear on the
>>> same end... at least based on the current definition of the dot notation.
>>> Personally, I think the dot should be displayed iff the association owns
>>> the end (which I think is a less common occurrence). I'll bring this
>>> issue up with the UML 2.2 RTF.
>
>
|
|
|
| Re: Navigability Semantics of Associations [message #476963 is a reply to message #476950] |
Wed, 20 February 2008 21:42 |
| Eclipse User |
|
|
|
Stefan,
This would result in a unidirectional assocation from clazz to clazz2, where
the "name1" association end is a property (with multiplicity 1..1) of clazz
and the "name2" association end is an owned end (with multiplicity 1..1) of
the new association.
Kenn
"SKuhn" <kuhn@oio.de> wrote in message
news:fpcgc9$3je$1@build.eclipse.org...
> hi kenn,
>
> this means that
>
> createAssociation(clazz, true, AggregationKind.COMPOSITE_LITERAL, "name1",
> 1, 1, clazz2, false, AggregationKind.NONE_LITERAL, "name2", 1, 1); //from
> the uml getting started example
>
> results in the 'correct' model?
>
> -stefan
>
>
>
> Kenn Hussey wrote:
>> Believe me, I know the feeling. ;)
>>
>> Kenn
>>
>> "Felix Dorner" <felix_do@web.de> wrote in message
>> news:fn5ejr$5u7$1@build.eclipse.org...
>>> Phew.. It's really great to have this list to discuss UML. I imagine
>>> just me and the 900 pages of specification... This really teaches one to
>>> not be awestruck by it but to discuss and question fishy-lookin
>>> concerns.
>>>
>>> Thanks,
>>> Felix
>>>
>>> Kenn Hussey wrote:
>>>> Ah, I see it now - you are right! It should be invalid for both the
>>>> non-navigability (x) and the ownership (dot) notations to appear on the
>>>> same end... at least based on the current definition of the dot
>>>> notation. Personally, I think the dot should be displayed iff the
>>>> association owns the end (which I think is a less common occurrence).
>>>> I'll bring this issue up with the UML 2.2 RTF.
>>
|
|
|
| Re: Navigability Semantics of Associations [message #625898 is a reply to message #476846] |
Mon, 14 January 2008 11:38 |
| Eclipse User |
|
|
|
Hi Felix,
Navigability and end ownership are two distinct notions in UML. Prior to
UML 2.0 the two concepts were not separated out. For example, if the end
was not owned by the classifier at the end then you could not navigate to
the other end. This however has changed.
Have a look at http://www.omg.org/cgi-bin/doc?formal/07-02-05, section 7.5
or http://www.omg.org/issues/uml2-superstructure-ftf.html#Issue 8956 .
There is new notation for this ( the dot at the end ).
It is possible to have the association own its ends and still be able to
navigate from one end to the other. This might be useful if you have some
hash table that gets dynamically populated at runtime. The table would
represent an association between two classes say, 'A' and 'B'. 'A' might
not have any property of type 'B' but at runtime, by virtue of looking it up
in the table, we can navigate to 'B', given 'A'.
In this case, we have an association between 'A' and 'B' and we can navigate
between them even though neither 'A' nor 'B' owns the end.
Cheers,
- James.
"Felix Dorner" <felix_do@web.de> wrote in message
news:20080112140505.33a78634@serenity...
> Hello,
>
> I try to understand the navigability semantics of associations.
> Because I am very insure if my below statements are correct, please
> correct them if neccessary:
>
> Suppose I have a Class Book and a Class Author.
>
> Task 1 - Bidirectional Navigability:
> ------------------------------------
>
> I'd like to have an association book_author between the two
> Classes which is navigable in both directions:
>
> a. Create an Association book_author.
>
> b. Inside the Author class I create an owned Property "books" of type
> Book set its Association Property to "book_author"
>
> c. Inside the Book class I create an owned Property "author" of type
> Author and also set its Association Property to "book_author".
>
>
> Task 2 - Unidirectional Navigability
> -------------------------------------
>
> I'd like to restrict navigability, only Author->Book should be
> possible.
>
> a. I change the owner of the "author" property from Book to the
> Association "book_author".
>
> Conclusion: Since the "author" end is now owned by the Association
> it is not navigable from the opposite end "book" anymore.
>
>
> Task 3 - Restore Navigability by making Use of an Association's
> "navigableOwnedEnd" property:
> ------------------------------------------------------------ ----
>
> If I also add the "author" end to the "ownedNavigableEnds"
> property of the Association, navigation from "book" to "author" would
> be possible again.
>
> Now I can't see any semantic difference between an end owned by an
> opposite end's class and that end owned by the Association and part of
> its "ownedNavigableEnd" property. Do I miss something?
>
> Task 4 - Make the Association not navigable at all
> --------------------------------------------------
>
> Make all ends owned by the Association. Why should one need this?
>
>
>
> Thanks for a discussion.
> Felix
|
|
|
| Re: Navigability Semantics of Associations [message #625916 is a reply to message #476850] |
Sat, 19 January 2008 15:46 |
| Eclipse User |
|
|
|
Hey James,
I am looking at the Superstructure 2.1.1 Spec and come up with the
following issue:
On Page 39 in the Description Section of "Association":
"An end property of an association that is owned by an end class [...]
indicates that the association is navigable from the opposite ends
[...]"
On Page 42 they explain the ownership "Dot" notation which is
illustrated on the next page by some Examples. To me the first example
of Figure 7.20 is a contradiction to the above citation:
The dot next to A indicates that A owns the "B" end of the Association.
According to the citation, this indicates that one can navigate from A
to B. However, the "B" end is indicated "non navigable" by the
"x" notation.
I see a clear contradiction here.
Further, on Page 43, "[...] navigability and end
ownership are orthogonal concepts each with their own explicit
notation". The example fully makes use of this statement,
but I just can't see how to model the mentioned example, i.e. an
owned association end which is not navigable.
Felix
|
|
|
| Re: Navigability Semantics of Associations [message #625919 is a reply to message #476863] |
Tue, 22 January 2008 10:06 |
| Eclipse User |
|
|
|
Felix,
I don't agree that there is a contradiction here.
The dot next to A indicates that B owns the "A" end of the assocation (not
the other way around) - remember that the notational attributes of an
association end are displayed on the end of the relationship line that's
opposite from its owner (I know, it's not necessarily intuitive)...
Kenn
"Felix Dorner" <felix_do@web.de> wrote in message
news:20080119214621.44908fbe@serenity...
>
> Hey James,
>
>
> I am looking at the Superstructure 2.1.1 Spec and come up with the
> following issue:
>
> On Page 39 in the Description Section of "Association":
> "An end property of an association that is owned by an end class [...]
> indicates that the association is navigable from the opposite ends
> [...]"
>
> On Page 42 they explain the ownership "Dot" notation which is
> illustrated on the next page by some Examples. To me the first example
> of Figure 7.20 is a contradiction to the above citation:
>
> The dot next to A indicates that A owns the "B" end of the Association.
> According to the citation, this indicates that one can navigate from A
> to B. However, the "B" end is indicated "non navigable" by the
> "x" notation.
>
> I see a clear contradiction here.
>
> Further, on Page 43, "[...] navigability and end
> ownership are orthogonal concepts each with their own explicit
> notation". The example fully makes use of this statement,
> but I just can't see how to model the mentioned example, i.e. an
> owned association end which is not navigable.
>
>
> Felix
|
|
|
| Re: Navigability Semantics of Associations [message #625924 is a reply to message #476866] |
Tue, 22 January 2008 13:05 |
| Eclipse User |
|
|
|
You are right. I just start working with the specs and still a little
green. Unfortunately my mistake does not change my interpretation as in
the mentioned example (Figure 7.20, first) _both_ ends have dots, so A
still owns the B end, while this end is at the same time marked
non-navigable by the small "x". As for now I am unsure if I again miss
some subtle aspect?
Felix
Kenn Hussey wrote:
> Felix,
>
> I don't agree that there is a contradiction here.
>
> The dot next to A indicates that B owns the "A" end of the assocation (not
> the other way around) - remember that the notational attributes of an
> association end are displayed on the end of the relationship line that's
> opposite from its owner (I know, it's not necessarily intuitive)...
|
|
|
| Re: Navigability Semantics of Associations [message #625925 is a reply to message #476870] |
Tue, 22 January 2008 13:39 |
| Eclipse User |
|
|
|
Ah, I see it now - you are right! It should be invalid for both the
non-navigability (x) and the ownership (dot) notations to appear on the same
end... at least based on the current definition of the dot notation.
Personally, I think the dot should be displayed iff the association owns the
end (which I think is a less common occurrence). I'll bring this issue up
with the UML 2.2 RTF.
Kenn
"Felix Dorner" <felix_do@web.de> wrote in message
news:fn5bac$83v$1@build.eclipse.org...
> You are right. I just start working with the specs and still a little
> green. Unfortunately my mistake does not change my interpretation as in
> the mentioned example (Figure 7.20, first) _both_ ends have dots, so A
> still owns the B end, while this end is at the same time marked
> non-navigable by the small "x". As for now I am unsure if I again miss
> some subtle aspect?
>
> Felix
>
> Kenn Hussey wrote:
>> Felix,
>>
>> I don't agree that there is a contradiction here.
>>
>> The dot next to A indicates that B owns the "A" end of the assocation
>> (not
>> the other way around) - remember that the notational attributes of an
>> association end are displayed on the end of the relationship line that's
>> opposite from its owner (I know, it's not necessarily intuitive)...
>
|
|
|
| Re: Navigability Semantics of Associations [message #625928 is a reply to message #476871] |
Tue, 22 January 2008 14:02 |
| Eclipse User |
|
|
|
Phew.. It's really great to have this list to discuss UML. I imagine
just me and the 900 pages of specification... This really teaches one to
not be awestruck by it but to discuss and question fishy-lookin concerns.
Thanks,
Felix
Kenn Hussey wrote:
> Ah, I see it now - you are right! It should be invalid for both the
> non-navigability (x) and the ownership (dot) notations to appear on the same
> end... at least based on the current definition of the dot notation.
> Personally, I think the dot should be displayed iff the association owns the
> end (which I think is a less common occurrence). I'll bring this issue up
> with the UML 2.2 RTF.
|
|
|
| Re: Navigability Semantics of Associations [message #625929 is a reply to message #476874] |
Tue, 22 January 2008 18:30 |
| Eclipse User |
|
|
|
Believe me, I know the feeling. ;)
Kenn
"Felix Dorner" <felix_do@web.de> wrote in message
news:fn5ejr$5u7$1@build.eclipse.org...
> Phew.. It's really great to have this list to discuss UML. I imagine just
> me and the 900 pages of specification... This really teaches one to not be
> awestruck by it but to discuss and question fishy-lookin concerns.
>
> Thanks,
> Felix
>
> Kenn Hussey wrote:
>> Ah, I see it now - you are right! It should be invalid for both the
>> non-navigability (x) and the ownership (dot) notations to appear on the
>> same end... at least based on the current definition of the dot notation.
>> Personally, I think the dot should be displayed iff the association owns
>> the end (which I think is a less common occurrence). I'll bring this
>> issue up with the UML 2.2 RTF.
|
|
|
| Re: Navigability Semantics of Associations [message #625934 is a reply to message #476871] |
Thu, 24 January 2008 12:28 |
| Eclipse User |
|
|
|
The UML 2.2 RTF issue can be found at
http://www.omg.org/issues/uml2-rtf.open.html#Issue12193
Kenn
"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message
news:fn5d9l$r6h$1@build.eclipse.org...
> Ah, I see it now - you are right! It should be invalid for both the
> non-navigability (x) and the ownership (dot) notations to appear on the
> same end... at least based on the current definition of the dot notation.
> Personally, I think the dot should be displayed iff the association owns
> the end (which I think is a less common occurrence). I'll bring this issue
> up with the UML 2.2 RTF.
>
> Kenn
>
> "Felix Dorner" <felix_do@web.de> wrote in message
> news:fn5bac$83v$1@build.eclipse.org...
>> You are right. I just start working with the specs and still a little
>> green. Unfortunately my mistake does not change my interpretation as in
>> the mentioned example (Figure 7.20, first) _both_ ends have dots, so A
>> still owns the B end, while this end is at the same time marked
>> non-navigable by the small "x". As for now I am unsure if I again miss
>> some subtle aspect?
>>
>> Felix
>>
>> Kenn Hussey wrote:
>>> Felix,
>>>
>>> I don't agree that there is a contradiction here.
>>>
>>> The dot next to A indicates that B owns the "A" end of the assocation
>>> (not
>>> the other way around) - remember that the notational attributes of an
>>> association end are displayed on the end of the relationship line that's
>>> opposite from its owner (I know, it's not necessarily intuitive)...
>>
>
>
|
|
|
| Re: Navigability Semantics of Associations [message #626049 is a reply to message #476875] |
Mon, 18 February 2008 12:42 |
| Eclipse User |
|
|
|
hi kenn,
this means that
createAssociation(clazz, true, AggregationKind.COMPOSITE_LITERAL,
"name1", 1, 1, clazz2, false, AggregationKind.NONE_LITERAL, "name2", 1,
1); //from the uml getting started example
results in the 'correct' model?
-stefan
Kenn Hussey wrote:
> Believe me, I know the feeling. ;)
>
> Kenn
>
> "Felix Dorner" <felix_do@web.de> wrote in message
> news:fn5ejr$5u7$1@build.eclipse.org...
>> Phew.. It's really great to have this list to discuss UML. I imagine just
>> me and the 900 pages of specification... This really teaches one to not be
>> awestruck by it but to discuss and question fishy-lookin concerns.
>>
>> Thanks,
>> Felix
>>
>> Kenn Hussey wrote:
>>> Ah, I see it now - you are right! It should be invalid for both the
>>> non-navigability (x) and the ownership (dot) notations to appear on the
>>> same end... at least based on the current definition of the dot notation.
>>> Personally, I think the dot should be displayed iff the association owns
>>> the end (which I think is a less common occurrence). I'll bring this
>>> issue up with the UML 2.2 RTF.
>
>
|
|
|
| Re: Navigability Semantics of Associations [message #626064 is a reply to message #476950] |
Wed, 20 February 2008 21:42 |
| Eclipse User |
|
|
|
Stefan,
This would result in a unidirectional assocation from clazz to clazz2, where
the "name1" association end is a property (with multiplicity 1..1) of clazz
and the "name2" association end is an owned end (with multiplicity 1..1) of
the new association.
Kenn
"SKuhn" <kuhn@oio.de> wrote in message
news:fpcgc9$3je$1@build.eclipse.org...
> hi kenn,
>
> this means that
>
> createAssociation(clazz, true, AggregationKind.COMPOSITE_LITERAL, "name1",
> 1, 1, clazz2, false, AggregationKind.NONE_LITERAL, "name2", 1, 1); //from
> the uml getting started example
>
> results in the 'correct' model?
>
> -stefan
>
>
>
> Kenn Hussey wrote:
>> Believe me, I know the feeling. ;)
>>
>> Kenn
>>
>> "Felix Dorner" <felix_do@web.de> wrote in message
>> news:fn5ejr$5u7$1@build.eclipse.org...
>>> Phew.. It's really great to have this list to discuss UML. I imagine
>>> just me and the 900 pages of specification... This really teaches one to
>>> not be awestruck by it but to discuss and question fishy-lookin
>>> concerns.
>>>
>>> Thanks,
>>> Felix
>>>
>>> Kenn Hussey wrote:
>>>> Ah, I see it now - you are right! It should be invalid for both the
>>>> non-navigability (x) and the ownership (dot) notations to appear on the
>>>> same end... at least based on the current definition of the dot
>>>> notation. Personally, I think the dot should be displayed iff the
>>>> association owns the end (which I think is a less common occurrence).
>>>> I'll bring this issue up with the UML 2.2 RTF.
>>
|
|
|
Goto Forum:
Current Time: Wed Jul 23 17:44:41 EDT 2025
Powered by FUDForum. Page generated in 0.06932 seconds |
Home