I am trying to model a robot controller I am working on. If I would think in Object-oriented design, I would come up with a component diagram like this :

Component diagram of the remote, using the RobotController, using the WheelsInterface

However, we use a data-oriented framework (ROS/Orocos), so components are linked together with "ports". In our system, for instance, the WheelsInterface has a output port actualVelocity and an input port commandVelocity ``

I am not sure how to represent this in UML. I have tried to represent output ports by interface realization and input port by interface dependency, but it seems wrong.

Component diagram with the interfaces circles representing the data ports

Is there a better way to represent the data flow between components in UML ? Or should I stick to the first diagram, bud add some kind of qualifiers to the lines?

  • Is it me or do you have all of the interface symbols backwards in the second diagram? Commented Nov 7, 2019 at 11:58
  • That's the point. All output ports are represented as interface realization and all input ports as interface dependency. For instance, Remote has an output port Commands, that is connected to the input port of the RobotController.
    – Hugal31
    Commented Nov 7, 2019 at 12:14
  • still seems backwards. Is the RobotController querying the Remote with some getCommand()? Commented Nov 7, 2019 at 12:37
  • The RobotController listens for the data wrote by the Remote. In code, looks like command = m_commandsInPort.read() in RobotController and m_commandsOutPort.write(command) in Remote. I know it's confusing, that's why I aks this question.
    – Hugal31
    Commented Nov 7, 2019 at 12:45
  • Whats confusing is that if the write and the read are complimentary then at some time the data exists between them somewhere in something. You seem to have not shown that something. If you're saying m_commandsInPort is a reference to Remote thru the Commands interface and m_commandsOutPort is a reference to RobotController then this read and write aren't talking to each other. What is sent through one doesn't end up coming out the other. Instead they are two completely different ways to send information from Remote to RobotController that have nothing to do with each other. Commented Nov 7, 2019 at 15:02

2 Answers 2


The root of many problems is trying to show information on a diagram that is not intended to use it this way. This is usually happening when you try to indicate the whole model on just one diagram.

The Components Diagram is a static view of the system. It shows connections and dependencies. The only information about the direction of data flow that can be read from it is who actually initiates the communication but does not depict the direction of the data flow.

To show the data flow, that is a dynamic (behavioural) part of your system you should use some other diagram(s). I would go for a sequence diagram (probably a few of them), however some other behaviour diagrams might do as well.

If you still insist on showing the data flow direction on the same diagram, there are two related possibilities. First of all, you should depict the components with ports (shown as small rectangles, from which the interface lines protrude rather than coming directly from the component itself).

Now you have two options. One is to use stereotypes for ports, marking them as <<in>> or <<out>> respectively. The other option is to use Profiles to extend the UML and, actually still by stereotyping, change its visualisation to have a small arrow inside indicating data flow.

Communication direction via ports' stereotypes

I am not sure if StarUML supports ports and if you can stereotype them there. I have also no idea if there is any tool other than some general diagramming tools like Visio or Dia that supports visual extension of UML, theoretically granted by profiles.

  • Or you can add a non standard flow of control arrow. Commented Nov 7, 2019 at 12:34
  • Indeed a sequence diagram would be helpful. But I am still willing to show the data flow on the connections. Unfortunately, my UML tool (StarUML) does not let my write arrows on the lines. I may use some custom stereotypes or something else.
    – Hugal31
    Commented Nov 7, 2019 at 12:50
  • @Hugal31 ascii --> art can be very expressive. Commented Nov 7, 2019 at 12:54
  • @Hugal31, I hope my addition will be helpful as it addresses the static part of the problem (ports that are in and out) and I believe now fully answers your question. I'm sorry I haven't been using StarUML at such level of details to know if it can support the suggested approach. As you can see Enterprise Architect does.
    – Ister
    Commented Nov 7, 2019 at 13:22
  • StarUML does have ports, but It seems unhappy to make ports implement interfaces. But stereotypes will be enough. Thank you for your response!
    – Hugal31
    Commented Nov 7, 2019 at 13:46

UML was lacking data flow diagrams for decades (which was - in my eyes - probably the biggest single mistake the UML designers ever made). Data flow diagrams are essential for modeling any kind of system which contains data processing components, with some input data, some processing and some output data (and disclaimer: these were >95% of the systems I had to deal with over the last 30 years). DFDs scale well to several layers of abstraction, they can be defined with a clear and strict semantics, and they can be even used for model driven approaches and code generation.

But since this diagram type was missing in UML, I have seen several people hesitating to use DFDs. They got the impression doing "something wrong", or maybe suboptimal "object oriented design". Nothing could actually be farther from the reality. I have also seen people arguing with strange excuses why data flow diagrams are not part of UML. This often gave me the impression those people have read tons of UML books, but were missing hands-on practical experience which diagrams are really useful in real-world software design, and which look only nice in theory.

Fortunately, several UML tool vendors provide DFDs as an extension to their standard UML diagrams. It seems they understood the need for such diagrams way better than the UML inventors. StarUML (which you mentioned in a comment) seems to have them, Visio does, Dia supports them, and Draw.IO has enough generic elements to support them as well.

Today, the best existing substitution in UML is AFAIK the Information flow diagram, which was introduced some time ago in UML 2.x. It is not a complete replacement for data flow diagrams, but it seems it would be sufficient for your example. The Wikipedia article about DFDs mentions also Activity diagrams as a replacement, but that is something where I think the Wikipedia article is IMHO misleading.

See also

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.