3

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.

Lemon Sky
  • 677
  • 4
  • 10
  • Everything I've read suggests that no one knows what this means. Everyone I've asked seems to be guessing. The accepted answer is downvoted. I'm sure the meaning is clear to someone somewhere, but it looks like putting it in a diagram largely confuses people, which is the opposite of what a diagram should do. The only way most people aren't confused by the difference is if they ignore it. – Scott Hannen Feb 09 '21 at 17:34

2 Answers2

0

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

Steve Harrison
  • 172
  • 3
  • 13
-2

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.

sim
  • 1,148
  • 2
  • 9
  • 18
  • Is the term "wiring dependency" and the fact that it only makes sense in one direction in the UML specification? Ultimately that is what I am looking for. People have different opinions about this, which is why I am searching for a reliable reference. – Lemon Sky Jan 15 '19 at 21:19
  • Ok, I think I found it. UML superstructure specification 2.4.1, section 8.3.1, "When a Dependency is wired from a Usage to an InterfaceRealization, the dependency arrow should be shown joining the socket to the lollipop." This is a "should"-specification and the spec says it uses the term "should" as per RFC 2119. Which means there "may exist valid reasons in particular circumstances to ignore a particular item". My interpretation therefore is that the opposite pointing arrow may be valid, and explicitly not forbidden (otherwise the spec would use "shall"). – Lemon Sky Jan 15 '19 at 21:31
  • Should means that the wiring dependency is optinal, because, as stated above, you already expressed the usage of the interface you only need it when want to add further dependency besides of the usage semantics :-). It is only a wiring dependency when it is in that direction. Every thing else is not a wiring dependency (this is not covered by should). When you model the dependency in oposite direction it means that the providing of an interface depends on th eusage of the same interface in a different class. What shall that mean? What do you want to express with that? – sim Jan 16 '19 at 12:11
  • If the direction of a dependency from an *interface realization* to an *usage* is valid syntax or not can even be doubted. From a meta model prespective this very basic part has quite a long history and suffers from its heritage (as many other things in um, too). A *dependency* is intended to point from a *named element* to an other one. Although the *named dependency* allows to point from an *element* to an other *element*, which are not required to be named. Thus it can be seem as ocnstraint on the basic type(which is not that good - but heritage). follow up in next comment... – sim Jan 16 '19 at 12:19
  • this is a follow up of a previous comment. And as neither the *usage* nor *interface realization* are *named elements* a dependency cannot be modelled between them. This holds for both directions. In case of the wiring dependency, it is explicitly allowed in the text and can be seen as shortcut. But it is not cleanly defined by the meta-model. The opposite direction is not even mentioned in the text. And all of this complex stuff leads to wide spread confusions and different interpretations. – sim Jan 16 '19 at 12:24