我们如何调用和表示像子作用域和父作用域那样的关联？
+--------------------+ +-------------------+
| parent scope | <――――――――――――――――――――――x | child scope |
+--------------------+ +-------------------+
父级到子级的关联是明确的，不允许父级访问子级。
然而，子对象与父对象的关联受到限制，子对象不能完全访问父对象，只能查找特定的标识符，但该标识符必须在子对象中丢失。
您的关系图意味着从Child scope到Parent scope的关联是可导航的，但从Parent scope到Child scope的关联是不可导航的。
导航是关于运行时效率的承诺：
Navigability意味着在运行时参与链接的实例(关联的实例(可以从关联另一端的实例高效访问。实现这种高效访问的确切机制是具体实施的。如果一端不可导航，从另一端访问可能是可能的，也可能是不可能的，如果是，则可能效率不高
-UML 2.5.1规范。
所以这不是一个"；被允许"；，而是关于这种访问的容易性和效率。
然而，你的图表和叙述之间不匹配。假设您的上下文中的可导航性是通过使用标识符来实现的，这是一种基于该标识符查找类实例的有效方法：
- 从
Child scope到Parent scope的可导航性意味着子级将知道其父级的标识符 - 从
Parent scope到Child scope的不可导航性意味着父级没有其子级的标识符，并且必须找到子类的所有实例并询问子级父级是谁。效率极低
从业务的角度来看(在"业务用例"中也是如此(，不存在可导航性的概念，此属性用于O.O编程中对象之间的链接。在业务用例中，箭头的方向实际上指示了在主要参与者触发用例之后信息的流向。大多数时候，由于存在"交互"，信息是双向的(例如，屏幕以视觉方式发送信息，并通过编码、鼠标事件等方式接收信息。如果信息只单向传播，则关系是单向的。例如，一个用例将数据发送给次要参与者(这是另一个系统(，而该系统在没有任何反馈的情况下"消耗"该数据。