Directedness and Navigability of Edges

[Paolo F Cantoni]

In a related topic ([size=13]XMI Import Data Corruption/Loss in EA 6.5 (802)[/size]) Darren and I mention our view that there is a problem with the way in which EA handles the storage and rendering of edges with respect to the UML notions of Navigability and Directedness.

The [size=13]UML 2.1 Superstructure (interim)[/size] Specification in 7.3.3 Association (from Kernel) defines navigability to have three states:

• Unspecified
  
• Non-Navigable
  
• Navigable

Navigable will cause an arrow head , Non-Navigable a cross and Unspecified nothing to be drawn at the appropriate end of the Association.  Thus UML specifies that Navigability is a property of the Edge (Association) End.  This is implemented in EA in the Navigability control of the Source Role and Target Role tabs of the Edge dialog.  These tabs should be, more correctly, named Origin End and Destination End.

The drawing of the arrow head implies a directedness for the edge.  If there is no arrow, it is non-directional.  If there is one arrow it is uni-directional or directed and if there are two arrows it is bi-directional.  Notice that the presence or absence of the cross is irrelevant.

A UML Association is therefore any one of non-directional, uni-directional or bi-directional

In the case of other edge types (For example, Generalization, Realization and Dependency) the allowable values for Navigability are more restrictive:  The only values are Navigable and Unspecified.  In the case of a  Notelink only Unspecified is allowed.  Generalization, Realization and Dependency are explicitly solely uni-directional whereas Notelink is solely non-directional.

When we draw an edge on a diagram, we start in one place (the origin) and draw to somewhere else (the destination).  For uni-directional association UML specifies that the end with the arrow head is the Supplier and the end without the arrow head is the Client.  It is natural that when we normally draw an edge, the origin is the Client and the destination the Supplier.  This is supported by EA for the directed edge types mentioned.  However, the support is inconsistent since the Navigability control is available for the Dependency and Realization relations, but (correctly) not for the Generalization relation.

EA, unfortunately, has a dropdown list on the General Tab of the Edge dialog called Direction which contains the values:
Unspecified, Source->Destination, Destination->Source, and Bi-Directional.  It will be apparent from the foregoing that this is a non-sequitur - that is, these values cannot follow from first principles and the UML specification.

So what does this dropdown hold?  If you experiment with the Navigability settings in the Role tabs, you will see that the Direction control is affected by the settings in the Role tabs.  The dropdown is thus a summary control for both the Navigabilities.  But the set of values shown is not correct.  The values should be:

(Origin)->(Destination)
------------------------------------------
Unspecified->Unspecified   ⁽¹⁾
Unspecified->Non-Navigable
Unspecified->Navigable   ⁽²⁾
Non-Navigable->Unspecified
Non-Navigable->Non-Navigable
Non-Navigable->Navigable
Navigable->Unspecified
Navigable->Non-Navigable
Navigable->Navigable

⁽¹⁾  The only valid combination that apply to solely non-directional relations (such as Notelink and the like).

⁽²⁾  The only valid combination that apply to solely uni-directional relations (such as Generalization, Realization, Dependency and the like).

To make things really clear, one could replace the names by their appropriate glyphs:

(Origin)->(Destination)
------------------------------------------
Unspecified->Unspecified   -----  -----
Unspecified->Non-Navigable   -----  ---x-
Unspecified->Navigable   -----  ---->
Non-Navigable->Unspecified   -x---  -----
Non-Navigable->Non-Navigable   -x---  ---x-
Non-Navigable->Navigable   -x---  ---->
Navigable->Unspecified   <----  -----
Navigable->Non-Navigable   <----  ---x-
Navigable->Navigable   <----  ---->

For those edges with dotted lines, the ----- would be replaced with -  -  -
For those edges with closed arrowheads, the > would be replaced with |>

Thus the default drawing of a Realization would be:
Unspecified->Navigable   -  -  -  -  -  |>

EA, Unfortunately, has a menu item <context menu>|Advanced|>Reverse Direction which merely swaps the ends (that is the origin becomes the destination and vice versa).  It does not change the value of the Direction dropdown on.  One might view this as strange until one realises (as we have explained above) that the name of the dropdown is really Navigabilities.

However, if you adopt our (more correct) nomenclature, we can propose the following:

For solely uni-directional relations, the menu item should be named: <context menu>|Advanced|>Reverse Direction and it will both swap the ends and swaps the navigability values in the ends.  As a consequence the summary navigability will appear unchanged, but the rendering will be reversed.

For relations that are more flexible in their navigability (such as Associations and the like), there can be up to two menu items: <context menu>|Advanced|>Swap Origin/Destination which will swap the ends (similarly to the current item) but since the navigability is a property of the end, it does not change the navigability of the end. This affects the way in which the relation is persisted.  As a consequence the summary navigability will change, but the rendering will not.

Further, if the relation has different navigabilites in both ends, an additional item: <context menu>|Advanced|>Swap Navigabilities will swap the navigability values for the origin and destination ends.  Both the summary navigability and the rendering will change.   (If the navigabilites are the same, then swapping navigabilities doesn't change any outcome)

In the case of solely non-directional relations (such as Notelinks) it follows, as a natural consequence, that it makes sense to always persist them in the same way.  We propose that in the case of a Notelink, the Note is always stored as the origin and the other end is always the destination.  This means that where the same Note is linked to more than one destination it will be consistently stored as the origin.  This applies in the case of the other end being either a vertex or an edge.

NOTE: We believe it should be possible to refactor existing edges to be consistent with this proposal, but would have to take advice from Sparx on this.

Summary:
The current EA interface for edges is:

• less than supportive of the UML 2.1 specification than it should be
  
• is to a significant extent self-inconsistent (and in the case of Dependencies violates the UML specification)
  
• would appear to have impacted the underlying design of both the database values and the supporting code (such as Import/export) such that refactoring in one area breaks functionality in others

Our proposal is:

• fully supportive of the UML 2.1 specification and first principles
  
• fully self-consistent
  
• would make both the database and other code much cleaner

Thoughts?  Votes?
Paolo & Darren

[size=0]©2007 Paolo Cantoni & Darren Sampson, Ripple Systems[/size]

[Paolo F Cantoni]

Some clarification on the above proposal, following some off-line feedback.

Section 7.3.3  Association (from Kernel) subsection Presentation Options of the UML 2.1 Specification offers the following:
Various options may be chosen for showing navigation arrows on a diagram. In practice, it is often convenient to suppress
some of the arrows and crosses and just show exceptional situations:

• Show all arrows and x’s. Navigation and its absence are made completely explicit.
  
• Suppress all arrows and x’s. No inference can be drawn about navigation. This is similar to any situation in which
  information is suppressed from a view.
  
• Suppress arrows for associations with navigability in both directions, and show arrows only for associations with one-way navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no
  navigation at all; however, the latter case occurs rarely in practice.

[/i]

[size=10][Edit due to further input in following posts][/size]
EA (as of build 802) does not support the cross rendering for non-navigable AssociationEnds.  This means that option 1 above is not currently available.  The third option explicitly assumes that there is no situation that navigation is unspecified («Unknown») - so the standard is actually erroneous in that statement.  The sentence should read:  In this case, the two-way navigability cannot be distinguished from situations where there is no navigation at all nor where it is uspecified.  We would contend that the situation where the navigation is (as yet) unspecified is not so rare at all.

In addition, there is a clear implication that the option chosen should, at least, be consistently applied on a per diagram basis (otherwise all bets are off!).  Moreover (it would appear implicitly that) the diagram should indicate (say, in the Diagram Notes) which notation is in effect.  Currently, this would have to be done manually.

Navigability only applies to Associations.  Those edge types that are, of their essence, uni-directional (Such as: Generalization, Realization, Dependency), or non-directional (such as: Notelink) shouldn't expose a navigability control (either in summary or against the end).  EA is currently inconsistent on this - some directional and non-directional edge types do and some don't.

Feedback welcome.
Paolo

[size=0]©2007 Paolo Cantoni & Darren Sampson, Ripple Systems[/size]

[jeshaw2]

Paolo;

A few thoughts upon reading your post.

EA (as of build 802) does not support the cross rendering for non-navigable AssociationEnds.  This means that option 1 above is not currently available.

In my opinion, EA must make this notation available--as well as the ownership dot.

The third option explicitly assumes that there is no situation that navigation is unspecified («Unknown») - so the standard is actually erroneous in that statement.

I'm not sure I understand this point--which statement? Is it erroneous because we are told to assume bi-directionality in this case?

The sentence should read:  In this case, the two-way navigability cannot be distinguished from situations where there is no navigation at all nor where it is unspecified.

Therefore the need for the cross notation to resolve the ambiguity.  I don't think this statement should be in the standard in any form of wording.

 We would contend that the situation where the navigation is (as yet) unspecified is not so rare at all.

Agreed, happens all the time at the CIM & PIM levels.

Navigability only applies to Associations.  Those edge types that are, of their essence, uni-directional (Such as: Generalization, Realization, Dependency), or non-directional (such as: Notelink) shouldn't expose a navigability control (either in summary or against the end).  EA is currently inconsistent on this - some directional and non-directional edge types do and some don't.

Have you considered the communicate associations in use cases.  The uni-directional actor/use case association defines the primary actor, associations without arrow heads signify secondary actors.

[Paolo F Cantoni]

Paolo;

A few thoughts upon reading your post.
[size=10][original quote lost by quoter][/size]
In my opinion, EA must make this notation available--as well as the ownership dot.

Well Jim, thanks to your prompting I went looking and EA (6.5/802) DOES support the full notation...  (I'll adjust the previous statements above.)  

I knew it supported the ownership dot via:  Association Role dialog [X] Owned checkbox.  I've just discovered the X for the non-navigability indicator is enabled via Diagram Properties... [X] Show Non-Navigable Ends.  Now unfortunately, I can't find how to set this on a per-repository basis, so it will have to be done on a per-diagram basis.  I guess EA's UI (Unique Interface) strikes again.  Also, I don't think I noticed this in any release notes so I can't say which version it came in with.   Perhaps the Sparxians can enlighten us?

[size=10][original quote lost by quoter][/size]
I'm not sure I understand this point--which statement? Is it erroneous because we are told to assume bi-directionality in this case?

It's erroneous in  suggesting there won't be much confusion.  (...Because the confusing situations are rare).  You've agreed the the confusing situations are much more common than the Specification suggests - so since the premise is wrong, the statement is wrong.

[size=10][original quote lost by quoter][/size]
Therefore the need for the cross notation to resolve the ambiguity.  I don't think this statement should be in the standard in any form of wording.

I agree with you, but if you HAVE to have such a statement it needs to be something like I stated.

[size=10][original quote lost by quoter][/size]
Agreed, happens all the time at the CIM & PIM levels.

Yes...  If you read between the lines, the Specification was principally written by PSM folks.

Have you considered the communicate associations in use cases.  The uni-directional actor/use case association defines the primary actor, associations without arrow heads signify secondary actors.

They should be covered with no loss of generality by the proposal.  Can you show where they aren't?

Thanks for the input,
Paolo

[jeshaw2]

Rereading the proposal after a good night's sleep, I think we are OK with the actor/use case association notations.

[KP]

Paolo,

That's a very long post that raises a lot of points. Here's a few thoughts of my own, in no particular order.

1. I don't think there are three states (navigable, non-navigable or undefined). That looks like two states, three notations.

2. While the 'x' notation for non-navigable association ends is certainly useful for some people, it is a new notation and hasn't yet earned equal billing with the well known "arrow or no arrow" equivalents that the majority of users will be using. You won't be seeing nine choices in the "Direction" control for the foreseeable: The four choices used with the "Navigable" control for the association ends allow all nine possible combinations for those who want to use them while not making life more complicated for those (the majority) who don't.

3. Bi-directional dependencies may or may not be valid UML. The client and source for dependency are both sets of type NamedElement[1..*] and there isn't an explicit constraint saying they can't be matching sets of NamedElement[2]. If you disagree, don't use bi-directional dependencies, but they may be useful for others.

4. The Direction control IS disabled for Realizations - not sure why you think it isn't.

5. Your objection to the UML spec's wording "however, the latter case occurs rarely in practice": they were saying that if you wish you can choose to use a modelling convention where an association with no arrowheads represents a bi-directional association, because associations which are non-navigable in both directions are rare. I don't think that's unreasonable.

Is there anything I've missed?

[darren.sampson]

1. I don't think there are three states (navigable, non-navigable or undefined). That looks like two states, three notations.

UML is all about notations - if there are three notations (arrow, cross, line [no arrow or cross]) then there are three states.  If I drew a state diagram for changing the state of an end, i'd certainly have three states for the end. Which one do you think isn't a state?

2. While the 'x' notation for non-navigable association ends is certainly useful for some people, it is a new notation and hasn't yet earned equal billing with the well known "arrow or no arrow" equivalents that the majority of users will be using. You won't be seeing nine choices in the "Direction" control for the foreseeable: The four choices used with the "Navigable" control for the association ends allow all nine possible combinations for those who want to use them while not making life more complicated for those (the majority) who don't.

The cross is as much a part of the UML 2.1 standard as the arrow.

The problem I have with the four "Direction" states is that there is a one to many mapping with the navigability in the ends.

If I have a source end with navigability "Not Navigable" and a target end with navigability "Navigable" the Direction will be "Source to Target".  But what happens if I change this to "Target to Source"?
Do I end up with
a) Source end "Navigable", Target end "Not navigable" or
b) Target end "Navigable", Target end "Not specified"

I don't see the problem with showing all nine possibilities - just list the common ones first and give them understandable names.  In fact, why not just show the graphical representations as Paolo "drew" them in the post (eg. ---->, -x-->, ----, etc)

3. Bi-directional dependencies may or may not be valid UML. The client and source for dependency are both sets of type NamedElement[1..*] and there isn't an explicit constraint saying they can't be matching sets of NamedElement[2]. If you disagree, don't use bi-directional dependencies, but they may be useful for others.

Fair enough - EA supports lots of things that are not standard UML, so as long as this is prohibited when EA is in "strict UML" mode, this is OK.  If you support bi-directional dependencies, why doesn't EA support all other connectors being bi-directional, and more so, all other connectors supporting non-navigable?

4. The Direction control IS disabled for Realizations - not sure why you think it isn't.

The comment here is that EA supports two concepts that aren't exactly the same
a) Changing the direction
There is only one valid combination of navigability for realisations so this shouldn't be allowed - and it isn't.
b) Reversing the ends
There's no reason why reversing the ends shouldn't be supported for realisations - it's a way of correcting a mistake (drawing the line the wrong way around) without deleting the connector and drawing it again.  This is disabled, but it shouldn't be.

5. Your objection to the UML spec's wording "however, the latter case occurs rarely in practice": they were saying that if you wish you can choose to use a modelling convention where an association with no arrowheads represents a bi-directional association, because associations which are non-navigable in both directions are rare. I don't think that's unreasonable.

It's just a pointless comment in the spec - either a notation is supported or it's not.

Darren.

[Paolo F Cantoni]

Darren's post covers the substantive response.  My post covers these specific issues.

[size=13][SNIP][/size]
4. The Direction control IS disabled for Realizations - not sure why you think it isn't.

Yes, the control is disabled, but since (unlike the Generalization) you can still get at the Navigability control for the Ends and enable/disable the arrows at will.  So the question is actually moot.  (My printed diagram can't tell which way I drew the Realization internally)

5. Your objection to the UML spec's wording "however, the latter case occurs rarely in practice": they were saying that if you wish you can choose to use a modelling convention where an association with no arrowheads represents a bi-directional association, because associations which are non-navigable in both directions are rare. I don't think that's unreasonable.

What Jim and I are saying is that it is reasonable (to think it rare) - but wrong...

"however, the latter case occurs rarely in practice" strikes me as the equivalent of the #HOPEFULLY compiler pragma...

Paolo

[KP]

It's just a pointless comment in the spec

Hardly pointless. There are millions of UML diagrams in existence that use the convention that an association with no arrowheads has bi-directional navigability, and that includes diagrams in every UML textbook ever written. Permission to use this convention needs to be given somewhere in the spec. I think we can agree that it could be worded better though.

Neil

[darren.sampson]

Hi Neil,

This point is probably the most minor in the list - what is your response to the others?

Maybe I can agree that the sentence is not worded well, but it adds nothing to the dot point it appears in.

UML is sufficiently vague in some areas that modelling conventions are needed within a company or project. I would think this goes without saying - however, to spell it out:  A UML diagram may be fairly readable to anyone with UML experience, however, the nuances of the diagram may be lost if the reader doesn't understand the company's modelling conventions.

A possible company modelling convention is:
An association which is shown on a diagram as having unspecified navigability at both ends (no arrows or crosses) is to be read as being bidirectionally navigable

There's nothing at all wrong with this.

It's interesting to note that the section of the UML spec we are discussing here is talking about ways to display diagrams, not the underlying metadata of the association. EA doesn't take any of the approaches for rendering associations listed in the spec by default, and two are not available at all even by enabling options:

- Show all arrows and x’s. Available in EA by enabling x's
- Suppress all arrows and x’s. EA doesn't seem to have the option for hiding arrows.
- Suppress arrows for associations with navigability in both directions, and show arrows only for associations with one-way navigability.  (ie. regardless of the metamodel underneath, don't differentiate between non directional or bidirectional navigability when rendering associations) EA doesn't seem to have this option either

I suppose it comes down to whether EA is a modelling application or a drawing application.  If just a drawing application then so long as it looks OK on paper then all is OK.  If it's a modelling application, then the metamodel needs to be correct and the rendering needs to be configurable to the needs of the reader.

Darren

[KP]

what is your response to the others?

This thread is now too long for me to read in the time spent waiting for my work to compile. Can you summarize your feature requests in as few words as possible, please?

[darren.sampson]

Hi Neil,

Paolo and I are happy to re-state our feature request, but we'd rather incorporate your personal (and Sparx) thoughts into the re-statement.

I responded to each one of your earlier thoughts here, and I'd appreciate your comments on my responses to items 1-4 (5 is covered by your post this morning)

Thanks!

[sl@sh]

Hello,

The issue I experienced appears to relate to this topic, so I decided to add it in here:

When using the Quicklink from one object to create a new object that is part of it I chose "Object --> Composition". As a result I got a new object and an association that has the filled out diamond attached to the new object's end, instead of the old object's. The association properties correctly show the old object as the source and the new object as the target. However, the source role shows 'Aggregation: none' whereas the target role shows 'Aggregation: composite'.

This behavior isn't quite what I expected, and since in class diagrams the filled out diamond is initially drawn attached to the old object, I strongly suspect a bug here. Or is there some obscure UML design rule that differentiates between class and object diagrams for some reason?

Moreover, and that is the main reason I posted into this topic: when I edit the properties of the newly (and wrongly) created association, I realized that there is a seperate flag to indicate ownership. As I understand UML, ownership is what differentiates aggregates from composites, so why can you select your aggregation as compopsite without also signalling ownership, and why can you define something to be owned without calling it a composite instead of an aggregate?

[Paolo F Cantoni]

Hi Sl@sh,

Your point is well taken.  But... You may not be aware that the Quicklink functionality you just mentioned didn't, in fact, create an EA Association but an EA Aggregation connector.  Open the connector's properties dialog and look at the title.

If you search for "Aggregation Association" under my name in the UML Forum you find me take issue with the existing EA Aggregation Element.  You may also find some points of direct relevance to your post.

We avoid EA Aggregations - like the plague...

Also if you search for Owner (again under my name) you'll also find some clarification of the checkbox you mentioned.

HTH,
Paolo

[sl@sh]

Thanks for pointing out the difference!

Looking at your previous comments on that issue i think I'll go with your advice and avoid EA aggregations.

However, one issue remains: when I draw an EA aggregate in an object diagram with an object as the source, the location of the diaomond is different from the result of the same operation within a class diagram, when drawing an EA aggregation from a class! When I check Tools->Options->Link->Draw Aggregations reversed, then, indeed, the drawing gets reversed - for both cases! So they still differ!

One more reason to avoid EA aggregates I guess....