Association roles and navigability
Associations between UML classes or data types may have a navigable direction. This can be from one class to the other (Source -> Destination or Destination -> Source), or both directions (Bi-Directional). Associations may also have unspecified direction, which in most cases will be the same as bi-directional, but this option should not be used. The navigable direction describe how implementations of the model can be navigated, and is symbolized with arrows in the diagram. In the figure above, all associations are navigable in both directions.
The navigable direction will have influence on implementation.
For GML implementation, it is stated in ISO19136 Annex E that all navigable ends shall be marked with an arrow. In other words, the navigable direction shall always be set.
Also, consider that bi-directional associations means that implementations of both classes know about each other. This may also make implementations more complicated - if both sides are mandatory, both classes must have reference to the other in an GML implementation.
Prefer one-way associations if it is not important that implementations of both classes know about each other
In implementations, associations will be similar to attributes. Therefore, it is important that
each navigable end shall have a role name. This is also stated in ISO19136 Annex E - and it shall be an "NCName", in the same way as attribute names.
In the figure above, an implementation of a Person class may have a reference to an implementation of a Car class, and this reference shall be called property. And vice versa - an implementation of a Car class shall have a reference to an implementation of a Person class, and the reference shall be called owner. But if we look at the association between Car and Wheel, we can see that the Car end have no name. So the Wheel does not know what to call its reference to a Car.
The multiplicity on an association end describes how many instances of one class that may or shall be referenced by the other. A Person may have none or many Cars (property), while a Car must have a Person (owner). A Committee must have two or more Persons (members), and a Person can be part of none or many Committees. And a Car must have three or more Wheels, while a Wheel can belong to none or one car.
Setting the multiplicity is also important for implementation.
ISO 19136 Annex E states that multiplicity for all navigable end shall be set explicitly
Multiplicity 1 and 1.. should be used with care.*
The consequence of setting the multiplicity to 1 or 1..* is that implementations of a class must always have this reference (similar to a mandatory attribute). If the multiplicity on the Car side of the Car-Wheel association had been 1, implementations of the Wheel class would have to have a reference to an implementation of a Car class. And the Wheel side is already mandatory (3..*). If the model had been like this, both classes would have to have reference to the other in an implementation, and would likely have ended up with duplicate information.