Data Flow Diagram Cheatsheet for Signal Processing
I've spent most of my career either writing signal processing software or telling other folks how to write it. By "signal processing software," I'm referring to that sub-niche within the niche that is embedded systems: numerically intensive algorithms, complex state machines, real-time requirements, hosted on half-baked hardware with only a couple of blinking LEDs to indicate status. Given these challenges, it simply makes no sense to design or document such a system with flow charts, which were invented before computers, way before, and needlessly confuse how data moves (data flow) with when (sequencing). Flow charts can't even depict a state machine of any real complexity. Some would-be Dr. Frankensteins try to graft a textbook-style signal processing "flow graph" onto a flow chart, yielding predictably horrific results.
Nor does it make sense to use UML, with its design-by-committee smell, emphasis on OO, and architect astronaut aspirations. Why, the most relevant UML model for signal processing software, the "activity diagram," doesn't even support nested models-within-models: it's entirely flat. That's because UML is geared for websites written in Java and business transactions, not OFDM receivers. Even if you do manage to munge UML to suit your needs, as I once did, nobody can interpret the eye-blisteringly ugly results without you standing over their shoulder. So why bother? (I will concede that UML statecharts are useful).
But enough ranting. Ed Yourdon has posted the entire text of his book, Modern Structured Analysis, on his website, including the critical chapter on data flow diagrams (DFDs). DFDs are easily learned and clearly distinguish between data processing versus state machine behavior. You can draw a DFD (on paper or with software--it doesn't matter), set it aside for several years, then pick it up and understand it. Most importantly, DFDs are actually useful: they capture both design essence and details of a system into a set of readable diagrams, and can yield meaningful insight.
So go read Chapter 9 of Ed Yourdon's wiki, or just print out my DFD cheatsheets below. Try using DFDs the next time you need to design or document your signal processing software, and you'll see what I mean.
