Non-standard use of navigability arrow on OntoUML diagrams

[SPowley]

A number of OntoUML models use the UML navigability arrow to imply additional semantics that are not compliant with the meaning defined in the UML 2.5.1 specification. For example, see Figure 3 in the D3FEND paper

According to the UML spec, navigability has a very limited meaning:

  11.5.3 Semantics
  11.5.3.1 Associations
 ... Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. 

In practice, the navigability arrow is retained in the specification for backward compatibility with version 1.x of the specification and has largely been replaced by the ownership end dot notation. For a helpful treatment of this aspect, see Getting it Right on the Dot.

My understanding is that in the OntoUML models, the navigability is instead used to assert the reading direction of the relationship in machine readable form, which is not properly supported with the solid triangle used to indicate reading direction in Visual Paradigm (i.e. VP does not always correctly store source and target). In any case, the semantics of the solid triangle notation are only very weakly defined by the UML spec.

  11.5.5 Examples
  .... The solid triangle indicates the order of reading

Some diagrams (as in the D3FEND example linked above) even mix both notations, which leads to further confusion.

To avoid confusion, I would recommend that at least the following measures are taken:

• Make it very clear in OntoUML documentation that the navigability arrow has been repurposed, and define clear semantics for its interpretation
• Explicitly deprecate the use of the reading direction arrow in Visual Paradigm models

Relying on repurposing of standard UML notation is a workaround at best, and does not provide a clean solution so I would propose to alternative options:

• Make use of UML association end role names to indicate the source and target of each association, and deprecate the use of both navigability arrows and reading direction arrows. This option has the downside of not being particularly intuitive to readers unfamiliar with UML.

• Use the UML profiling mechanism (see "12.3 Profiles" in the UML spec) to define an extension to the language and create a new type of relationship that adds the required semantics to the standard association relationship. UML provides an abstract metaclass 'directed relationship'. By inheriting properties from both 'association' and 'directed relationship' the new relationship, which I would name 'directed association', provides a clean method of achieving the desired purpose. A custom notation that does not duplicate any existing UML connector can also be defined and applied with the profile to provide human readability as well as standard-compliant machine-readable semantics. Given that OntoUML in Visual Paradigm is implemented as a plugin with menu support for selecting types, the use of a custom notation should not present an obstacle in terms of usability.

  7.8.5 DirectedRelationship [Abstract Class]
  7.8.5.1 Description
  A DirectedRelationship represents a relationship between a collection of source model Elements and a collection of target model Elements. 
  
  11.5 Associations
  11.5.1 Summary
  An Association classifies a set of tuples representing links between typed instances.
  

I would recommend the 'directed association' solution. This has the following advantages over the existing approach and alternatives:

• Standard-compliant solution
• Machine readable and human readable
• Intuitive notation for non-UML users without risk of confusion with standard UML

[pedropaulofb]

@SPowley, thank you very much for your contribution. As the UFO/OntoUML Catalog only keeps models created on the Visual Paradigm editor + OntoUML Plugin, I am moving this issue to the ontouml-vp-plugin project to be there evaluated and treated.