UML syntax: association directions

[ronaldtse]

Navigation option

• A directed association is an association that lets you navigate from one of the participating association roles to the other.
• It has an open arrowhead at the side of the class to which we can navigate.
• Both multiplicity and role names can also be denoted at the side to which we cannot navigate, in this case the property belongs to the association rather than to a class.

Navigation exclusion

• To explicitily exclude a navigation direction, we put a small cross to the side of the class that shouldn’t be navigated to.

Possible forms of interpretation for navigability (UML 1.x & 2.0)

1. All arrows and crosses means that all navigation options are explicitly denoted.
2. No arrows and crosses means that there is no statement on navigability. There is no way to tell the difference between some kind of navigation that may be present and some kind of unspecified navigation.
3. Arrows only for associations with a navigation direction means that there is no unspecificied navigability, that is, no arrow has a meaning equal to the cross representation. This is the common interpretation of the UML metamodel diagrams.

Proposal:

// 1

class Invoice
class Address
Invoice X-> (contains) Address[1]

// 2

class Station
class Car
Station -> (contains) Car[1]

// 3

class Insurance
class Contributor
Insurance -> (has) Contributor[1]

Reading direction VS navigation direction

• The navigation direction tells us whether an object can access another object.
• The reading direction is used to understand the association name

[w00lf]

Navigation option

• A directed association is an association that lets you navigate from one of the participating association roles to the other.
• It has an open arrowhead at the side of the class to which we can navigate.
• Both multiplicity and role names can also be denoted at the side to which we cannot navigate, in this case the property belongs to the association rather than to a class.

Navigation exclusion

• To explicitily exclude a navigation direction, we put a small cross to the side of the class that shouldn’t be navigated to.

Possible forms of interpretation for navigability (UML 1.x & 2.0)

1. All arrows and crosses means that all navigation options are explicitly denoted.
2. No arrows and crosses means that there is no statement on navigability. There is no way to tell the difference between some kind of navigation that may be present and some kind of unspecified navigation.
3. Arrows only for associations with a navigation direction means that there is no unspecificied navigability, that is, no arrow has a meaning equal to the cross representation. This is the common interpretation of the UML metamodel diagrams.

Proposal:

// 1

class Invoice
class Address
Invoice X-> (contains) Address[1]

// 2

class Station
class Car
Station -> (contains) Car[1]

// 3

class Insurance
class Contributor
Insurance -> (has) Contributor[1]

Reading direction VS navigation direction

• The navigation direction tells us whether an object can access another object.
• The reading direction is used to understand the association name

What about the association keyword? Should we support both arrow and explicit association keyword? We also have syntax from ucd gem:

CLASS_RELATIONSHIP = [ "directional" / "bidirectional" ] ( "dependency" / "association" / "aggregation" / "composition" ) NAME [ FROM ] [ TO ]

Example:

class Node
class Element {
   directional dependency Node
   bidirectional association Node
}

[ronaldtse]

OK, let's base it on ucd gem syntax.

[w00lf]

Association direction syntax was implemented in the gem