Can you use use read/write on data flow chart?

Question

If I have a front-end application that reads from the API of a backend, then I would have a data flow chart like this, because the data flows from the backend to the frontend:

However, when I would like to emphasize that this is a read only API, and that the front-end cannot write to the backend, I feel like have to turnaround the arrow, saying "The Frontend reads from Backend":

But this would conflict with the data-flow arrow, because the arrow indicates the direction of the flow:

How do you represent a read/write relation to a data-flow diagram?

Answer 1

Data-flow diagrams use arrows to show the direction of the flow of data. Whether you use Gane & Sarson or Yourdon & DeMarco), a unidirectional arrow means an unidirectional flow:

• Your first diagram means that the data flows from the back-end to the front-end and only in that direction. There is no need to tell that it's read-only, because the flow is unidirectional.

• If you wanted the front-end to read and write data from/to the back-end, you'd need a second arrow in the opposite direction. A common practice is to use a bidirectional arrow (Yourdon uses it in several examples, Gane and Sarson even recommend it for keeping diagrams simple).

• If you want to have it read-only, but indicate the data elements used to find the relevant data, you may use Gane & Sarson's notation of "search argument specification" (which is meant to apply to data stores and not processes):

  Source: Structured System Analysis, Chris Gane & Trish Sarson

Your second diagram would be misleading: not only would it show the flow in the wrong direction, but in addition, the DFD convention is to label the arrows with the kind of data that flows along:

Arrows should be named to indicate the meaning of the data that moves along the flow that is, a noun.
Data flows with a verb name signify a process that has been omitted. Data flow in and out of a process must be altered in some way.
- Source : Visual Paradigm tutorial

This convention explain also why double-sided arrows are quite rare in practice, as soon as you label the flow: the flow back would have a slightly different name (e.g. updated data, corrected data, validated data).

The only ambiguity in your diagram is who initiates the flow: is it the front-end that reads or the back-end that writes? But this is normal: it's not the purpose of this kind of diagrams to go in such details. You could add an arrow "request data" to show that the front-end initiates the communication, but this would quickly overload your diagram and the added precision would come at the expense of the readability.