UML dependency in a UML deployment diagram with two arrow heads

Question

Can I draw mutual dependencies between two artifacts in a deployment diagram as a dashed line with two arrow heads? Or is this a no-go in UML?

Answer 1

The answer to your question depends on what you use the UML diagram for. A dashed line with two arrow heads is not formally specified by the UML specification.

There are two main uses for UML:

1. As a communication tool between people. People are generally good at inferring the meaning of a variation of a known pattern, which means that you don't have to follow the UML specification strictly as long as the drawing clearly communicates what you intend.

2. As a visual specification to generate code from. In this case, part of the audience to the UML diagrams is a computer program. Computer programs are not good at inferring meaning. If you use UML in this way, you must follow the specification very strictly if you want your diagrams to be correctly understood by the computer tooling. You may even have to restrict yourself to a subset of UML.

Answer 2

(It is rather a no-go in architecture than in UML.) Formally it should be two cyclic lines with arrow, which more clearly exposes the cyclic dependencies.

But for documenting things the act of abbreviating, blending out details, to provide a digestible overview is important. Nicest maybe would be <===> to show that there are two directions. Otherwise one has to pay careful attention - for an unexpected arrow usage.

In conclusion: better refrain from <--->.

Answer 3

A generalized dependency in UML is drawn with a dashed line; the direction of the dependency is indicated with an arrow. The current UML specification doesn't define a bidirectional dependency, but even so, (1) people do need to, and do depict this sometimes, and (2) there's no UML police out there that will hunt you down for using UML in the wrong way. If you need to make an adjustment to communicate an idea more clearly, and it's not so wildly contrary to the established standards as to introduce confusion, just go for it.

P.S. Most dependencies between software components (and people surrounding them) are in some way bidirectional, but in UML and other design diagrams we simplify this to simple directed relationships by focusing on a subset of the dependencies that can be expressed in code, or is otherwise conceptually useful. So these diagrams are an idealization, which works well most of the time. But sometimes there's a need to go beyond that model and take other things that influence code into account (e.g. two microservices can be codependent due to interaction between the teams that own them, and this can reflect in code, and affect design decisions - even though conceptually only one depends on the other).