modelstocode

Open full view…

Executable Models - Data Flow Definitions

siegristj
Tue, 04 Jul 2017 12:54:50 GMT

Hello All, In the executable UML approach, a model consists of three separate descriptions: the class model, the state model and the actions. Class models are based on the Codd relational model and the state model is based on Moore-type finite state machines. Is there an equivalent formalism underpinning the actions? Under the action section, action languages and data flow diagrams are discussed, but as far as I can tell these don't have a sound mathematical basis like the other two parts of the model. Some work has been done around trying to formalize DFDs with Petri Nets (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.9398) but it isn't clear that this has gained widespread adoption in the industry. It seems that the actions need to be defined in terms of two different mathematical formalisms: one closer to predicate logic for specifying the 'what' and another more like Petri nets or temporal logic for specifying the timing/concurrency. Has this been nailed down formally or is this still an open area for investigation?

siegristj
Tue, 04 Jul 2017 13:40:58 GMT

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)

Leon Starr
Tue, 04 Jul 2017 14:22:30 GMT

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!

andrewmangogna
Sun, 09 Jul 2017 19:05:10 GMT

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.