提供/必需表示法中的接口之间的 UML 依赖关系答案

【问题标题】：UML dependency between interfaces in provided/required notation提供/必需表示法中的接口之间的 UML 依赖关系
【发布时间】：2019-01-12 21:22:07
【问题描述】：

提供接口和所需接口之间的依赖箭头表示什么确切，方向是什么意思？

在我的理解中，提供的“棒棒糖”是对接口的实现关系，所需的“套接字”是对接口的使用依赖。

一个接口依赖于另一个接口，甚至依赖于它自己有什么意义？下面是我如何阅读上面的左图。

我认为有意义的是组件之间的依赖关系，如下所示，但这不是接口依赖关系所显示的。

Google 搜索显示了许多可能的意见，我们将不胜感激得到证实的答案（可能带有指向相应 UML 元模型的链接）。

【问题讨论】：

我读过的所有内容都表明没有人知道这意味着什么。我问过的每个人似乎都在猜测。接受的答案被否决。我相信某个地方的人很清楚其含义，但看起来将其放在图表中会使人们感到困惑，这与图表应该做的相反。大多数人不会对差异感到困惑的唯一方法是忽略它。

标签： dependencies uml

【解决方案1】：

虽然您的第二个示例看起来更直观（它似乎与球窝指示的依赖关系反转一致），但组件图的依赖关系箭头旨在说明数据的运行时流。所以第一张图是对的。我们仍然可以从插座中推断出插件设计。

对于显式调用提供的接口的组件，您会看到从调用组件延伸到被调用组件的棒棒糖的依赖箭头。

当您尝试使用在组件边界内显示具有接口的类的白盒组件图来说明时，情况会变得更加奇怪。实现箭头反方向，箭头有一个闭合三角形。

当您将 UML 1.0 与 UML 2.0 标准（球和插座总是耦合在一起）进行比较时，这种混淆会进一步加剧。

【讨论】：

【解决方案2】：

类上的socket表示该类使用接口，ball表示该类提供接口。因此，它是显示从类到接口的使用和实现的另一种风格。正确地说，这里的意思是使用关系，而不是依赖关系。使用关系表示依赖元素的实现依赖于独立元素。依赖意味着依赖元素的实现或/和规范依赖于独立元素。

在您的情况下，您所展示的这种关系，从所需接口指向提供的接口（在套接字和球表示法中）是所谓的连线依赖。在 opoosite 方向上使用依赖是没有意义的。当然，这些连线依赖并不是为了表达接口具有自依赖，但由于不吉利的符号，它通常会被误解。在 interface requires 和 interface provoding 之间建立依赖关系的目的最初是为了增加使用关系和依赖关系之间的细微差别，即用户还依赖于规范的其他方面，而不仅仅是提供的契约，例如资源规范或时间限制.今天，这种理解已经完全退化了，它只是用来通过显示属于一起的东西来提高图表的可读性。

为了澄清你的误解（这是一个很常见的误解），依赖不是从接口到自身，依赖是从需要接口到提供接口。认为，接口的提供和要求也是模型中的一个元素。

仅在模型的静态元素之间使用连接依赖关系，例如类、组件或类的端口（不是部件/对象）。当您想表达对象/部件的依赖关系由特定的其他对象/部件解决时，您对这两个实例进行建模并在实例或实例上显示的端口之间使用连接器（或从它派生的东西） .想了想，当静态元素有端口时，端口需要绑定。连接器只能在实例之间使用，不能在它们的分类器之间使用。

【讨论】：

“连线依赖”这个词和它在 UML 规范中只在一个方向上有意义的事实是什么？最终，这就是我要寻找的。人们对此有不同的看法，这就是我寻找可靠参考的原因。
好的，我想我找到了。 UML 上层结构规范 2.4.1，第 8.3.1 节，“当依赖关系从 Usage 连接到 InterfaceRealization 时，应该显示依赖关系箭头将套接字连接到棒棒糖。”这是一个“应该”规范，该规范说它根据 RFC 2119 使用“应该”一词。这意味着“在特定情况下可能存在忽略特定项目的正当理由”。因此，我的解释是相反的指向箭头可能是有效的，并且明确不被禁止（否则规范将使用“shall”）。
应该意味着连接依赖是可选的，因为如上所述，您已经表达了接口的使用，您只需要在除了使用语义之外添加更多依赖时才需要它:-)。当它在那个方向时，它只是一个布线依赖。其他所有东西都不是连线依赖（这不包括在 should 中）。当您对相反方向的依赖关系进行建模时，这意味着接口的提供取决于不同类中相同接口的使用。那意味着什么？你想表达什么？
如果从接口实现到用法的依赖方向是有效的语法，甚至可以怀疑。从元模型的角度来看，这个非常基本的部分具有相当长的历史并且受到其遗产的影响（就像许多其他东西一样）。 dependency 旨在从一个命名元素 指向另一个元素。虽然 named dependency 允许从一个 element 指向另一个 element，但不需要命名。因此，它看起来像是对基本类型的约束（这不是那么好 - 但遗产）。在下一条评论中跟进...
这是对先前评论的跟进。由于 usage 和 interface implementation 都不是 named elements，因此无法在它们之间建模依赖关系。这适用于两个方向。在接线依赖的情况下，它在文本中明确允许，可以看作是快捷方式。但元模型没有明确定义它。文中甚至没有提到相反的方向。所有这些复杂的东西都会导致广泛的混淆和不同的解释。