UML dependency between interfaces in provided/required notation

user_10802859 0
Viewed 1869

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

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.

enter image description here

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

enter image description here

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

dependencies uml
2 Answers

Although your second example seems more intuitive (it seems to align with the dependency inversion indicated by the ball and socket), the dependency arrows for component diagrams are intended to illustrate run-time flow of data. Therefore the first diagram is correct. We can still infer the plug-in design from the socket.

enter image description here

For components calling a provided interface explicitly, you would see the dependency arrow extending from the calling component to the lollipop of the called component.

enter image description here

It gets weirder when you try to illustrate using white-box component diagrams that display classes with interfaces within the component boundaries. Realization arrows go the other way and have a closed-triangle for the arrow.

enter image description here

This confusion is further exacerbated when you compare UML 1.0 to UML 2.0 standards where the ball and sockets are always coupled together.

enter image description here

user_24989140

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.

user_63564320
Related