UML dependency between interfaces in provided/required notation

Question

What exactly does the dependency arrow between provided and required interface signify and what does the direction mean?

In my understanding, the provided "lollipop" is a realization relationship to an interface, and the required "socket" is a usage dependency to an interface.

How does it make sense for an interface to have a dependency to another interface or even to itself? The below is how I read the left diagram above.

What makes sense in my mind is a dependency between components as shown below, but this is not what the interface dependency shows.

A Google search shows many possible opinions, a substantiated answer (perhaps with a link to the corresponding UML meta model) would be appreciated.

Answer 1

The socket on a class denotes that the class uses the interface and the ball denotes that the class provides an interface. Thus it is an alternate style of showing usage and realization from classes to an interface. To be correct, it is a usage relation what is meant here, not a dependency. The usage relation indicates that the implementation of the depending element is depending on the independent element. A dependency means that the implementation or/and specification of the depending element is depending on the independent element.

In your case, this kind of relation you are showing, pointing from a required interface to provided interface (in socket and ball notation) is a so called wiring dependency. Using the dependency in opoosite direction does not make sense. These wiring dependencies are not intended to express that the interface has a self dependecy, of course, but it is commonly misinterpretation due to an unlucky notation. The purpose of wiring dependencies between interface requiring and interface provoding was originally intenden to add the small difference between usage and dependency relations, i.e., the user also depends on other aspects of the specification than just the provided contract, e.g., resource specifications or time constraints. Today, this understanding is totally degraded and it is just used to improve the readability of diagrams by showing what belongs together.

To clean-up with your misunderstanding (which is quite a common one), the dependency is not from the interface to itself, the dependency is from the interface-requiring to the interface-providing. Thought, the providing and the requiring of the interface is an element in the model, too.

Wiring dependencies are only used between static elements of the model, e.g., classes, components, or ports of classes (not parts/objects). When you want to express that the dependency of a object/a part is resolved by a specific other object/part then you model these two instances and use a connector (or something derived from it) between the instances or the ports shown on the instances. Thought, when the static element has ports the ports need to bound. Connectors can only be used between instances not between their classifiers.