Navigability

[SF_lt]

this is related with other my post about navigability and OCL - it's a pity, that there was no replays:
http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=UMLPRO;action=display;num=1161725485

UML specification states, that navigable end is represented by arrow link end. If both ends are navigable, both link ends can have arrows or don't.

Then how to read this example Shouldn't package end have named end due to the navigability directed by arrow end from packate to stuff?



More examples could be found in UML Superstructure  & other documents

[Paolo F Cantoni]

As I read the [size=13]UML 2.1 Superstructure (interim)[/size] Specification (6.5.2 Diagram format), this is now a non conforming representation.

That is to say that since both ends are named it is, prima facie, navigable in both directions.  

If the Association is navigable in both directions, then under UML 2.1 there should be NO arrows.

The diagram is therefore non-conformant.

In addition, since setting the EA association to be bi-directional will cause EA to draw arrows at both ends, EA is therefore (currently) non-conformant.

HTH,
Paolo

[SF_lt]

I agree with Paolo, that provided example is non-conformant with the UML 2.1.

On page 24, figure 7.5 of UML Superstructure is also non-conformant if strictly to follow their's own (OMG) conventions. For example, in figure 7.7 conformant and non-conformant links are used  

[Paolo F Cantoni]

I agree with Paolo, that provided example is non-conformant with the UML 2.1.

On page 24, figure 7.5 of UML Superstructure is also non-conformant if strictly to follow their's own (OMG) conventions. For example, in figure 7.7 conformant and non-conformant links are used  

You could add Figures 7.6 and 7.8...

See my tag line...  
Paolo

[Eve]

From what I see the reference given for conventions is actually a convention adopted from UML 1.x but is no longer valid in UML 2.1.  However some diagrams haven't been updated.

(NOTE: This convention was inherited from UML 1.x and was used in the initial versions of the specification because there was no explicit notation for indicating association end ownership. Such a notation was introduced in revision 2.1 (see the notation subsection of the Association metaclass on page 37) but was not applied to the diagrams in the specification due to lack of tool support. In accord with the new notation, the ownership of an association end by the association would continue to be shown by leaving the end unmarked, but the ownership of an end by the classifier would be shown by marking that classifier-owned end with a dot.)

Figure 7.23 and its description clearly shows that you can draw navigability arrows on both ends.

Actually, navigability doesn't mean a whole lot at all in UML 2.1.

Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends

It's only talking about efficiency of navigation and in such terms that only the presence of an arrow really means anything at all.

Edit: I found the reference Paolo was talking about.

[SF_lt]

Simon, 6.5.2 chapter on page 17 says:

An association with one end marked by a navigability arrow means that:
• the association is navigable in the direction of that end,
• the marked association end is owned by the classifier, and
• the opposite (unmarked) association end is owned by the association.

and

An association with neither end marked by navigability arrows means that:
• the association is navigable in both directions,
• each association end is owned by the classifier at the opposite end (i.e., neither end is owned by the association).

I agree, that from a practical point of view, navigability doesn't mean a lot as association end ownage by association

[Eve]

Yes, that's what I read, and that's what the note that I quoted applies to.  Basically what it comes down to is that the diagrams in the UML 2.1 spec are frequently UML 1.3 diagrams, not UML 2.1.

However, when modelling with UML 2.1 those conventions do not apply.

[Paolo F Cantoni]

OK Simon,

Now we're all agreed...    What's the outcome?  Is EA currently non-conformant for Associations?  (Bi-directional gives 2 arrows instead of none)

BTW: I don;t think that dictum apples to edges other than Associations.  Thus Bi-directional Dependencies should still have arrows at both ends...

My AU$0.05

Paolo

[Eve]

No, I don't think it is.  As I said, Figure 7.23 shows the UML 2.1 notation for associations navigable in both directions to use the arrow head on both ends.

[Paolo F Cantoni]

No, I don't think it is.  As I said, Figure 7.23 shows the UML 2.1 notation for associations navigable in both directions to use the arrow head on both ends.

Sorry Simon, I missed the reference (to 7.23)...  
This is how I see it now...

6.5.2 basically says the standard is self inconsistent (basically becuase they haven't updated all the diagrams to be 2.1 conformant).

Figure 7.23 is a normative statement describing what the UML 2.1 notation should be....

Consequently, EA IS conformant to UML 2.1.

As a consequence, if the original diagram (posted by SF_lt) were drawn by EA 6.5(799.) with Direction: set to Bi-Directional, there should be arrows at both ends with the shared aggregation diamond at the Package end.

This would be UML 2.1 conformant.

Is it now a case of... "by George he's got it!"?

Paolo

[Eve]

"by George he's got it!"?  

As I see it, the original diagram is showing the following.

• A Package object can navigate to a collection (and the members of the collection) of Stuff Objects.
  
• The collection listed above has a name stuff.
  
• A Stuff object may or may not be able to to navigate to the corresponding Package object.
  
• If it can it may or may not be efficient.
  

Further to that, because the spec doesn't mandate the use of end ownership notation.  The following may be useful.

If we assume that end ownership notation isn't being used then we should probably use the convention from before the introduction of end ownership that a navigable end end equates to an owned attribute by the class.  This would then mean that Package has an attribute by the name stuff.
eg.

Code: [Select]

stuff : Stuff [*]
On the other hand, because the package end is not navigable, there is no attribute for the Package in Stuff.

The equivalent represented with end ownership notation would have a dot at the end of the navigability arrow.

[Paolo F Cantoni]

[size=13][SNIP][/size]
On the other hand, because the package end is not navigable, there is no attribute for the Package in Stuff.

The equivalent represented with end ownership notation would have a dot at the end of the navigability arrow.

While I agree with what you've said, what is the function of the +package then?

Paolo