Search code examples
navigationumlassociationsclass-diagram

UML Non-Navigable Relationships - Use or Example


Can any one give me a real life use or an example of a relationship where both (all?) ends are non-navigable ? (Similar to the image below)

enter image description here


Solution

  • According to the UML standard (section 11.5.3.1 about association semantics):

    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. 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.

    Example 1

    So let's imagine the relation between a UserAccount and a CLearTextPassword:

    • User account doesn't store the password in clear. It stores a hash of that password. With a hash of cryptographic quality, you can't navigate from UserAccount to ClearTextPassword.
    • Conversely, with a known ClearTextPassword you can't directly find the UserAccount. You first have to compute the hash. In the end, it is possible to navigate, but it's inefficient, as the calculation might be heavy.

    Example 2

    Let's imagine a secured ledger. Every Transaction in that ledger is recorded by an entrusted User. But the ledger will not keep any reference to the User : it will only keep a digital signature of the transaction. I know it sounds stupid at first sight, but imagine a voting machine that must guarantee anonymity of votes...

    So there is an association between User and Transaction:

    • at any point of time, you can verify for a specific Transaction, if it was recorder by a given User (existence of association).
    • you can't navigate from the User to the Transactions that he/she recorded: you miss the private key that is only under control of the user, you can't compute the hash of transactions that you don't know in advance, so you're unable to recompute the signature (which is the only connecting element).
    • Conversely, you can't navigate from the Transaction to the User : the only way you could find back is to verify the signature with the public key of all users, to find out the matching one. It's feasible, be would definitively be highly inefficient.