arrow heads

[timothy.hilgenberg]

is any one else having problems with arrow heads used with aggregation? I've followed the online help and it worked for some of the aggregations, but not for all, even in the same diagram.  Perhaps I'm again missing something, but my direction drop downs have:
Source -> Destination, not Source -> Target

If I reverse the direction I get the arrow head (and  yes I've set show arrow head in the Object configuration) when I then change the direction back to the way I want it, the arrow head disappears! I've even recreated the links time and again withour effect.

The problem is I've distributed the model with the arrow heads in a different UML program, so I need them.
Help - pleasehttp://

[thomaskilian]

Obviously the appearance is not orthogonal:
unspec: -------*
bidirect: <------>*
dest->source: <----*
source->dest: -----*
One should expect ----->* in the latter case?

[timothy.hilgenberg]

yes - that what I did expect, and oddly enough it works with a large number of aggregations, but not with all - and there is no difference between them! Annoying.

T

[Jacques_Ronaldi]

What is the "meaning" of that? I mean, how can you have a UNIDIRECTIONAL navigability from the source to the target??? Obviously, if the target is the container, it MUST have navigability to its contained object, no? Seems to me only target to source and bidirectional navigability make any sense.

[timothy.hilgenberg]

Sorry I obviously didn't express myself very clearly.

What I want is: [source]---><>[target]

What has me stumped is that I manage to get this for some links but not for others.

Hope this is clearer?

[thomaskilian]

Hi Sparx,
this really looks like a bug since you can't distinguish between unspec and source>dest.

[KP]

The arrowheads denote navigability, i.e. whether the element being pointed to is visible to the element at the other end of the association. If you have an arrowhead at only one end of an association then you are implicitly denying presence of an arrowhead at the opposite end of the association. Therefore, what ---><> appears to imply is that the child is not in its parent's scope; the parent is composed of elements that it cannot reference. Is that really what you are trying to show?

[sargasso]

IMO Agregation implies navigability from container to containee.  Thus [ ]<------<>[ ] implies bidirectionality - again IMO    i.e. I want the implementor to include a specific accessibility from the containee to the container.

BTW
How you get [ ]-----><>[ ] is by mucking around with the aggregation settings on the roles and then jigging the association direction.


Haven't got much time today.


Bruce

I just re-read this - I dont know whether I am agreeing with KP or not??  
I agree with the unidirectionality imposed on associations by one arrowhead  but maybe I have been assuming the implicit navigability on aggregations?  Did I dream it up or does any of the high church UMLists remember a reference to this (I couldn't find one in 2.0)

B

[KP]

That's OK Bruce, I don't know whether I agree with me or not either! Take a look at this picture.

I've cheated in displaying the 3rd one: it normally displays the same as the 1st.

Now, if a parent always has navigability to its child, then you only ever need use two of these connectors, but which two? Under presentation options for associations, UML2.0 gives 3 choices: show all arrowheads (use 2 and 4 in the drawing), suppress all arrowheads (use 1 and 1) or suppress arrowheads on bidirectional links (use 1 and 4). 3 doesn't get used in any of those choices.

However, does it ever occur that a parent doesn't have navigability to its child...?

[sargasso]

Logically - No, since then one couldn't ever add or remove objects from the collection.
Illogically - it is conceiveable that you could implement a collection that could not reference its contents, but still manage the addition or removal of (anonymous) contents.
:-/
B

[thomaskilian]

IMHO you should either suppress this illogical possibility or simply show it as expected (with the arrow).  

This discussion looks like the sophism: The man from crete who states that all men from crete are liers.  

[angel-o-sphere]

Hi,

Sargasso wrote:

IMO Agregation implies navigability from container to containee.  Thus [ ]<------<>[ ] implies bidirectionality - again IMO  

Intuitively one would agree with you, however you are wrong

[]<>-------[] does not say anything about the navigation!!  In language like C++/Java or even Lisp however the "natural" implementation leads to navigatability from left to right. The container can navigate to its parts. But the same aggregation is implemented in a DB via SQL in the opposite way! The part element will have a field with the ID of the container. The whole aggregation is solved conceptually in the opposite way.

So, if you like to forget intuition and specify precisly, then we are here:

[ ] <>------ P // no navigation specified, final navigatability depends on implementation constrains
[ ] <>------> P // navigation from container to part only
[ ] <><----- P // navigation form part to container only, natural if you have a "qualified" aggregation or you are in a table based system (SQL-DB)
[ ] <><-----> P // navigation into both directions

That above was "precise". But its usually not necessary to be that precise.

What about:

[ ] (parent) <>---------------------> (child)[]

Now I added roles for both ends of the aggregation. Now its basicly specified wrong, as we used the arrow for only one direction. But we gave the component a role name. While this is formal a contradiction it looks nicer and intuitively its clear that the part should have a reference back to its owner called "parent".

angel'o'sphere