Return to Answer

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

• What is the UML analogue to the Data Flow Diagram from Structured Analysis?

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

• What is the UML analogue to the Data Flow Diagram from Structured Analysis?

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 in 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

• What is the UML analogue to the Data Flow Diagram from Structured Analysis?

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

• What is the UML analogue to the Data Flow Diagram from Structured Analysis?

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, several people think when they model flow diagrams, they do "something wrong", or 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 DFD as an extension to the 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, Dia supports them, and Draw.IO has enough generic elements to support them as well.

Today, the best existing substitution in UML is the Information flow diagram, which was introduced in 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

• What is the UML analogue to the Data Flow Diagram from Structured Analysis?

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 in 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

• What is the UML analogue to the Data Flow Diagram from Structured Analysis?