3

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?

Improve this question
8
  • 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. 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. 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

Reset to default
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.

Improve this answer
5
  • 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. 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. 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! Commented Nov 7, 2019 at 13:46
3

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 might be an Activity diagram, but only when used for modeling Object Flows which seem be have become available some time ago during the development of UML 2.x. In UML 1.x Activity diagrams were only suitable for control flows, and the latter still is probably the most popular "use case" for ADs. The option of using an Activity diagram as an "Object Flow diagram" seems to be heavily underepresented in the public perception.

I also found this article about the UML Information flow diagram, from some UML 2.5 beta draft.

See also

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.