In a related topic ([size=13]XMI Import Data Corruption/Loss in EA 6.5 (802)[/size] (http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1167792327;start=0#2)) 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] (http://www.omg.org/cgi-bin/doc?ptc/2006-04-02) 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 (1)
Unspecified->Non-Navigable
Unspecified->Navigable (2)
Non-Navigable->Unspecified
Non-Navigable->Non-Navigable
Non-Navigable->Navigable
Navigable->Unspecified
Navigable->Non-Navigable
Navigable->Navigable
(1) The only valid combination that apply to solely non-directional relations (such as Notelink and the like).
(2) 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]
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]