Home » Modeling » UML2 » Navigability Semantics of Associations
|
Re: Navigability Semantics of Associations [message #476850 is a reply to message #476846] |
Mon, 14 January 2008 16:38 |
james bruck Messages: 1724 Registered: July 2009 |
Senior Member |
|
|
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 15:06 |
Kenn Hussey Messages: 1620 Registered: July 2009 |
Senior Member |
|
|
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 17:42 |
Stefan Kuhn Messages: 355 Registered: July 2009 |
Senior Member |
|
|
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] |
Thu, 21 February 2008 02:42 |
Kenn Hussey Messages: 1620 Registered: July 2009 |
Senior Member |
|
|
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 16:38 |
james bruck Messages: 1724 Registered: July 2009 |
Senior Member |
|
|
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 #625919 is a reply to message #476863] |
Tue, 22 January 2008 15:06 |
Kenn Hussey Messages: 1620 Registered: July 2009 |
Senior Member |
|
|
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 #626049 is a reply to message #476875] |
Mon, 18 February 2008 17:42 |
Stefan Kuhn Messages: 355 Registered: July 2009 |
Senior Member |
|
|
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] |
Thu, 21 February 2008 02:42 |
Kenn Hussey Messages: 1620 Registered: July 2009 |
Senior Member |
|
|
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: Thu Mar 28 11:34:15 GMT 2024
Powered by FUDForum. Page generated in 0.04892 seconds
|