UML component diagram named association to show dependency between components

Question

Can I use directed named association on component diagram to show fact that "sys A" sends data to "sys B"?

Example:

Answer 1

No, you should use general purpose dependency instead, with optional title.

However, the title is not very common in this context. Better use some other diagrams (sequence for example) to show the communication details (e.g. open connection, send data, close connection, etc).

If there is a well defined interface between those systems, you can indicate that as well like this:

Association is used between two classes to show that their instances are potentially connected (again, not for data flow indication).

Answer 2

If sys A sends information to sys B and you're not interested in how exactly the transmission takes place, then that is a classic application of the Information Flow connector.

A Dependency would in this case say that sys A needs (is dependent on) sys B for something. An Information Flow often (but not always) goes in the opposite direction of a Dependency, since it is typically the receiver that needs the sender.

There are many different ways of showing these types of relationships, and the best one depends on the situation. If your focus is on the type of information being transmitted, then Information Flow is the best fit. If your focus is on the way the transmission takes place, something with an Interface, possibly an Assembly, is better.

EA actually allows you to specify an Information Flow over an Assembly, so you could even combine the two. It's all down to what exactly you want to express.

Answer 3

In UML 2.0 the concept behind association is vague, read this article: http://www.uml-diagrams.org/uml-core.html (search for "Semantic Relationship"). Association denotes a "semantic relationship" between two components, and I think it wouldn't be appropriate for data flow. I think that even dependency isn't appropriate for data flows: maybe the client depends from the supplier, maybe the opposite is true... so the arrow can be very confusing. The lollipop notation is the best, IMHO: it shows clearly that there is a component providing an interface, and another one requiring it. You can use stereotypes on the interface to show the type of communication/data transfer, and labels to make clear what data is transferred. The book "Documenting Software Architectures" adopts another style, using prevalently associations: see p.145. It's similar to your initial proposal, but with explicit roles and without arrows. I think isn't a really satisfactory solution, without stereotypes...