Data flow diagrams, also called DFDs or threat modeling diagrams.
Many people have presented various different ways to craft data flow diagrams over the years. This is an attempt to both be precise about what this defninition of a "v3 DFD" is, and also to encourage people to think about diagramming techniques themselves as something that, like code, can be specified and evolved over time, and labeled with a version.
- A V3 DFD uses 5 symbols. A rectangle represents an external entity, a person or code outside your control. A rounded rectangle represents a process. They're connected by arrows, which can be single or double headed. Data stores are represented by parallel lines. A trust boundary is a closed shape, usually a box. All lines are solid, except those used for trust boundaries, which are dashed or dotted. (There is no "multi-process" symbol in DFD3.)
- It must not* depend on the use of color, but can use color for additional information.
- All elements should have a label.
- You may have a context diagram if the system is complex. One is not required.
Are more space-efficient in a large diagram than circles.
Clearly show what's inside, in a way that arcs often fail to do. Dashes and dots are clearly different from other elements and reproduce clearly with black and white printers.
Are easier to draw. They don't show initiation of a connection, which is sad, and that can be shown with one arrowhead filled, the other open.
Some approaches refer to complex processes, indicated by a doubled (concentric) circle. When to use them was never made clear, and so they're a bit of a distraction and I recommend against them.
I'm told that Gane and Sarson also used rounded rectangles long before me. (Gane, Chris; Sarson, Trish. Structured Systems Analysis: Tools and Techniques, 1979.). According to Richard Botting's CS372 course notes Yourdon and De Marco also used sharp rectangles for external entities.