提供/必需表示法中的接口之间的UML依赖性

Question

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

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

一个接口对另一个接口甚至自己具有依赖关系有什么意义？以下是我阅读上面左图的方式。

在我看来有意义的是组件之间的依赖关系，如下所示，但这不是界面依赖关系所显示的。

Google搜索显示了许多可能的意见，我们将为您提供充分的答案（也许带有指向相应UML元模型的链接）。

Answer 1

尽管您的第二个示例似乎更直观（它似乎与球和插座指示的依赖关系倒置一致），但是组件图的依赖关系箭头旨在说明数据的运行时流。因此，第一个图是正确的。我们仍然可以从套接字推断出插件设计。

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

当您尝试使用白盒组件图进行说明时，这会变得很奇怪，该组件图显示了具有组件边界内的接口的类。实现箭头则相反，箭头具有闭合的三角形。

当您将UML 1.0与UML 2.0标准进行比较时，这种困惑会进一步加剧，在UML 2.0标准中，球和承窝总是耦合在一起。

Answer 2

类上的套接字表示该类使用接口，而ball表示该类提供接口。因此，这是显示从类到接口的用法和实现的另一种样式。正确的说，这里是使用关系，不是依赖关系。使用关系表明依赖元素的实现取决于独立元素。依赖性意味着从属元素的实现或/和规范取决于独立元素。

在您的情况下，您正在显示这种关系，即从必需的接口指向提供的接口（以套接字和球标记表示）是所谓的接线依赖。在相反的方向上使用依赖没有意义。当然，这些布线相关性并不旨在表示该接口具有自相关性，但是由于运气不佳，通常会导致误解。最初在接口需求和接口推荐之间建立连接依赖关系的目的是增加使用和依赖关系之间的细微差别，即用户不仅依赖于所提供的合同，还依赖于规范的其他方面，例如资源规范或时间限制。如今，这种理解已经完全退化，它仅用于通过显示一起构成的东西来提高图表的可读性。

为了消除您的误解（这是很常见的错误），依赖性不是从接口到其自身，而是从需要接口到提供接口。思想，接口的提供和需求也是模型中的一个元素。

接线依赖关系仅在模型的静态元素之间使用，例如，类，组件或类的端口（不包括零件/对象）。当您要表达某个对象/零件的依赖性已由特定的其他对象/零件解决时，则可以对这两个实例建模，并在实例或实例上显示的端口之间使用连接器（或从其派生的东西） 。认为，当静态元素具有端口时，需要绑定端口。连接器只能在实例之间使用，而不能在其分类器之间使用。