Towards Separation of Concerns in Flow-Based Programming (2015) [pdf]
orbit.dtu.dk
orbit.dtu.dk
"Flow-based Programming"/"FBP" is a subtype of "dataflow" programming as I understand it. The distinguishing characteristic of "dataflow" is that the program is represented as a directed graph, where data moves across arcs connecting nodes.
From there we have "synchronous dataflow"/"asynchronous dataflow", "fine-grained/coarse-grained" dataflow (nodes as machine-level instructions vs. nodes as arbitrarily complex functions), and so on.
Going from the definition above, what distinguishes FBP within "dataflow" are 1) that the nodes are "processes", and 2) that execution is asynchronous.
I wish that "flow-based programming"/"FBP" advocates would place it deliberately within the hierarchy of "dataflow". I appreciate the historical forces which have prevented this, but it is confusing when you come to the subject as an outsider.
For a nice writeup on dataflow see this 2004 paper, especially section 2.1 "The Pure Dataflow Model" on pages 3-4: http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Liter...
Regarding distinguishing features though, AFAIK, one of the more important ones is that in FBP, connections between processes are done via named ports on processes, and that the wiring of these connections is thus enabled to be done separately from the process implementation itself. Dataflow, AFAIK, does not specify how the data network is specified.
We tried to describe this feature under the "Reusable component" with a figure (fig 3) in this (open access) paper: https://academic.oup.com/gigascience/article/8/5/giz044/5480... (link goes directly to the relevant section).
The rewriting is limited to be performed in terms of a fixed set of patterns called "advices". There are two fundamental advices ("observer": branching an edge and "adapter": breaking an edge) and one special case ("collector": apply an observer to each top level node in a composite node).
A Java implementation was developed.