UML 不可导航关系 - 使用或示例
UML Non-Navigable Relationships - Use or Example
任何人都可以给我一个现实生活中的用途或一个关系的例子，其中两个（所有？）端都是不可导航的？ （类似于下图）
我没有真实世界的例子，但这意味着 C 和 D 一定不认识对方。这是一种反联合。与其中一个对象的死亡迫使另一个对象死亡的复合聚合有点相反。
P.S。将两名嫌疑人带入两个审讯室。他们有一个协会，但都必须知道另一个的状态。非常构造，但这是我能想到的最好的。
根据 UML 标准（关于关联语义的第 11.5.3.1 节）：
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.
示例 1
那么让我们想象一下 UserAccount 和 CLearTextPassword 之间的关系：
- 用户帐户未明文存储密码。它存储该密码的哈希值。使用加密质量的散列，您无法从
UserAccount 导航到 ClearTextPassword。
- 相反，对于已知的
ClearTextPassword，您无法直接找到 UserAccount。您首先必须计算哈希。最后，可以导航，但效率低下，因为计算量可能很大。
示例 2
让我们想象一个安全的分类账。该分类账中的每个 Transaction 都由受托人 User 记录。但是分类帐不会保留对 User 的任何引用：它只会保留交易的数字签名。我知道乍一看这听起来很愚蠢，但想象一下 voting machine that must guarantee anonymity of votes...
所以User和Transaction之间存在关联：
- 在任何时候，您都可以验证特定的
Transaction，它是否是由给定用户记录的（关联的存在）。
- 您无法从
User 导航到 he/she 记录的 Transactions：您错过了仅在用户控制下的私钥，您不能计算您事先不知道的交易的哈希值，因此您无法重新计算签名（这是唯一的连接元素）。
- 相反，您无法从
Transaction 导航到 User ：您可以找回的唯一方法是使用所有用户的 public 密钥验证签名, 找出匹配的。这是可行的，但肯定会非常低效。
任何人都可以给我一个现实生活中的用途或一个关系的例子，其中两个（所有？）端都是不可导航的？ （类似于下图）
我没有真实世界的例子，但这意味着 C 和 D 一定不认识对方。这是一种反联合。与其中一个对象的死亡迫使另一个对象死亡的复合聚合有点相反。
P.S。将两名嫌疑人带入两个审讯室。他们有一个协会，但都必须知道另一个的状态。非常构造，但这是我能想到的最好的。
根据 UML 标准（关于关联语义的第 11.5.3.1 节）：
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.
示例 1
那么让我们想象一下 UserAccount 和 CLearTextPassword 之间的关系：
- 用户帐户未明文存储密码。它存储该密码的哈希值。使用加密质量的散列，您无法从
UserAccount导航到ClearTextPassword。 - 相反，对于已知的
ClearTextPassword，您无法直接找到UserAccount。您首先必须计算哈希。最后，可以导航，但效率低下，因为计算量可能很大。
示例 2
让我们想象一个安全的分类账。该分类账中的每个 Transaction 都由受托人 User 记录。但是分类帐不会保留对 User 的任何引用：它只会保留交易的数字签名。我知道乍一看这听起来很愚蠢，但想象一下 voting machine that must guarantee anonymity of votes...
所以User和Transaction之间存在关联：
- 在任何时候，您都可以验证特定的
Transaction，它是否是由给定用户记录的（关联的存在）。 - 您无法从
User导航到 he/she 记录的Transactions：您错过了仅在用户控制下的私钥，您不能计算您事先不知道的交易的哈希值，因此您无法重新计算签名（这是唯一的连接元素）。 - 相反，您无法从
Transaction导航到User：您可以找回的唯一方法是使用所有用户的 public 密钥验证签名, 找出匹配的。这是可行的，但肯定会非常低效。