I'm trying to make a DFD for this scenario: after admission, the patient gets the service he needs.

I've been trying to do it using this diagram (there are 3 available services): enter image description here

but I don't think it's going to work like this, maybe there is a way to avoid condition at the first place?

and how processes should be numbered in this case?

  • DFD is not a part of UML standard. I'll remove respective tag. Edit: It seems there are too many pending edits now. Please remove the tag yourself.
    – Ister
    May 14 at 17:04
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
    – Community Bot
    May 14 at 19:16

1 Answer 1


Dataflow diagrams are not as powerful and standardized as UML activity diagrams; there is no notation for conditions.

The usual practice would be to have three outgoing dataflows, that each describe the data that the Admit process could send to each of the subsequent alternatives. Perhaps only the patient id. Perhaps nothing, but Admit stores customer records in a datastore, and the others read the customer data from the datastore. If admission doesn't collect all the data, it might even be necessary to link external entity Patient to the other processes as well.

Typically, the conditions would be described in the documentation of the first process, clarifying when it will send the data to the other processes and under which conditions (outside the diagram).

About the numbering, it's not representing the chronology. It's not like an uml communication diagram, where you would use numbering for sequential chronology and letters for the alternatives. In a DFD, the processes are uniquely numbered at one level (and the next level takes the numbering of the previous level as prefix to build a unique id according to the decimal numbering).

  • DFDs are different from Activity diagrams, but whether they are less powerful or not is debatable, that's like comparing apples and oranges. I agree to all what you wrote about how a DFD would have to look like for this case, but I am unsure if the OP really wants to draw a DFD (though they said so, but I guess they simply got the terms wrong). It seems they really want to draw an Actitivity diagram.
    – Doc Brown
    May 15 at 5:55
  • ... btw, I find myself using DFDs way more frequently than ADs, so less powerful or not, IMHO they are much more useful.
    – Doc Brown
    May 15 at 5:59
  • @DocBrown Sure, Activity diagrams are a different beast. However, with activity diagrams and its object flows and its object stores, one may represent almost everything that you can represent with a dataflow diagram. With the control nodes you can even represent more (for example the conditions OP is looking for). This is why I claim they are more powerful. And they have the advantage of a more precise semantics and standardization (when dfds have multiple notational variants that depend on the authors).
    – Christophe
    May 15 at 6:07
  • On the other side dfds are simpler (only 3 symbols needed), more flexible (no need to chose object types to be exchanged), and more convenient for showing interactions with external entities. So there may be reasons for continuing using them.
    – Christophe
    May 15 at 6:17
  • For me, the main advantage of DFDs is that they scale to different levels of abstraction. One can use them for showing the data flow at the level of components inside a program, they can be used for showing the data flow between different programs or processes, or they can be used to show the data flow between whole systems. You are right, the DFD notation isn't well standardized, but the semantics can always be defined as strict as you want them to be.
    – Doc Brown
    May 15 at 15:36

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.