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