I'm a haskeller, so I'll speak for pure functional programming. The first thing that comes to my mind is commutative diagrams. These can be used to describe how functions and structures interact with each other; however, they rather define invariants/laws than behaviour.
Another thing useful to know when thinking about evaluation of lambda calculus (or higher-level languages based thereon) are expression graphs, as used in graph reduction. They let you see the structure of your expression, including sharing. Of course, this only makes sense as long as the code is pure, i.e., no mutations happen.
A third kind of diagram, useful to visualize how data is passing though functions, are different kinds of data flow diagrams, like the ones used for arrows (which can be used for normal functions too, since (->)
is an arrow), or SICP's "Henderson diagrams" (see Figure 3.31 and the paragraph above it in section 3.5.2 Infinite Streams). These show how individual functions are "plugged together". Another perspective on this are the diagrams used for drawing stream processing/pipe and filter style, like marble diagrams, which focus more on a notion of time (and, as opposed to arrow diagrams, do represent individual values).