Navigability means according to the UML specifications:
that instances participating in links at runtime (instances of an
Association) can be accessed efficiently from instances at the other
ends of the Association. The precise mechanism by which such efficient
access is achieved is implementation specific. If an end is not
navigable, access from the other ends may or may not be possible, and
if it is, it might not be efficient.
In your example, this means that:
the association can be read in both ways; navigability does not change the fact that there is an association with two sides;
an instance of OrderDetail
can easily and efficiently find the associated Item
object;
it is not guaranteed that Item
could find all its associated OrderDetails
, and if it could, it might not be efficient;
navigability has nothing to do with the multiplicity.
There is no rule about how to implement such a link. This is completely implementation dependent. Examples for your case:
- In a RDBMS, an
OrderDetailTable
would have a mandatory ItemId
column with the Id
of the related Item
, and the ItemTable
would have Id
as primary key. As a consequence, it would be extremely efficient to find the Item
fir navigation. It would also be possbile to find all the OrderDetails
that are related to an Item
, but it might not be as efficient if the necessary indexes are not created.
- In Java, the
OrderDetail
class could have a integer member ItemId
. You could have an ItemRepository
class with a method findById()
that would return for a given integer the corresponding Item
instance
- In C++ you could have in the
OrderDetail
class a member that points to a specific Item
. In this case, the opposite navigation is practically impossible if there isn't a pointer in the other direction.
As you see, this in very dependent of the implementation language, the related idioms and techniques chosen (e.g. integer id vs pointer). It also depends on the multiplicities, the kind of ownership, as well as access path designed for other associated classes.