It seems that the timing/data flow rules are part of the Executable UML specification as described here: Leon Starr: Time and Synchronization in Executable UML (http://www.ooatool.com/docs/Starr09.pdf)
I know folks have played around with formal DFDs and Petri Nets, etc. I think Andrew may be more in touch with that stuff and will leave it to him to comment. As for my quoted pdf, the more recent version (and accompanying video) are up here: https://www.modelint.com/mbse I'm planning to migrate that content over to executableuml.org at some point. Both describe the time and synchronization rules defined in the Mellor/Balcer Executable UML book and those have their roots in Leslie Lamport's work on clock synchronization in distributed networks. But this does not at all address computation or data flows. It's squarely directed at interacting state models. My work on action language (I'll let Andrew speak for himself) leans heavily on C.J. Date's writing on proper updating of database variables. Also, there's this book Applied Mathematics for Database Professionals, deHaan, Lex, Koppelaars, Toon, Springer/Apress which I've found quite helpful. The focus then is not so much on the DFD, which follows pretty simple rules, but on the nature of the actions inside of t hose bubbles. It's is not clear to me that we need a lot of complicated math for these things. Then again, I'm neither a computer scientist nor a mathematician!
Larry Constantine is often credited with using Data Flow diagrams first. Certainly, Tom DeMarco popularized the technique. The theoretical basis comes from a paper by Martin and Estrin from 1969. It is certainly not difficult to make up a precise set of execution rules for data flow computation. These topics fall generally in the category of "process algebra". Another influential example is Tony Hoare's "Communicating Sequential Processes". A book that is readily available off the Internet and worth a good read. It's just important to keep in mind that our purpose in Executable UML is to describe the computational flow in a manner that removes any arbitrary sequencing. That goal can be met by both graphical and textual means. As for Petri Nets, I spend a good deal of time many years ago trying to convince myself that they would be a superior formulation to state models for modeling class lifecycles. I gave up on the effort for two reasons: 1. Most formulations of Petri Nets assume one net to capture the whole problem. This is the same problem that we see in convention al UML where folks will try to construct one state model for the whole system (the mother of all state models approach). Such models are very complex and need lots of "features" like Harel state charts or Petri Net style synchronization to be able to capture the problem. Now there are things like Colored Petri Nets that might be adaptable to modeling the lifecycle of instances, but ... 2. You just don't need it. Simple Moore state models have well defined properties, a minimal set of execution rules and cover the needs to model the lifecycle of a class in much simpler terms. Simpler is better at easing the translation burden and the expressive power of the formalism is derived from the composition of sets of interacting state models rather than some towering hierarchy of more complex rules.