Is there a model of computation based on discrete event dynamic systems?

Question

I asked a question here about discrete event dynamic systems. They are systems whose state evolution depends on asynchronous events. It can be combined with flow to produce a hybrid system.

There must be an event-based model of computation, since it is so applicable to user interactions. Could someone point me in the right direction? Is there a canonical model of computation for event-based systems?

Answer 1

Let's first look at what Wikipedia says:

• the theory of computation is the branch of mathematics and computer science that deals with how efficiently problems can be solved on a model of computation;
• a model of computation is a model which describes how a set of outputs are computed given a set of inputs; they can be classified into three categories:
  • Sequential models, including
    • Finite state machines
    • Pushdown automata
    • Turing Machines
  • Functional models, including
    • Lambda calculus
    • Recursive functions
    • Combinatory logic
    • Cellular automata
    • Abstract rewriting systems
  • Concurrent models, including
    • Kahn process networks
    • Petri nets
    • Synchronous Data Flow
    • Interaction nets

All of these are mathematical formalisms to model the behavior of discrete event systems. To be more precise, for each of them, there is a whole family of related formalisms, and many more formalisms exist outside of these families, thousands or tens of thousands in all, ranging from very popular to very obscure.

You're looking for ones that are event-based. Flow-based models are often considered to be event-based: what flows in can be regarded as a stream of events. Furthermore, finite automata were conceived of as an event-based formalism: they were introduced in a memo titled ''Representation of Events in Nerve Nets and Finite Automata''. Concurrent modeling techniques (e.g. Kahn process networks, Petri nets, Communicating Sequential Processes) are often based on finite state machines or variants of that idea. Techniques based on communicating state machines operating in parallel are popular in industry. Their models consist of components passing messages, or events, or data items, to each other over channels. This is really flexible: you can use it for modeling events, or dataflow, or literal message passing, or the flow of abstract information in, let's say, some office workflow process.

You say you're looking for something other than flow-based models, something suitable for describing user interaction. I've worked with modeling technology for embedded systems that makes this distinction. It has two kinds of communication:

• asynchronous: used for data flow processing or event flow processing where data or events flow in on a streams, have a bit of processing done, then flow out on another stream
• synchronous: procedure calls: one party instigates communication and waits for the response, the other party responds; used for interaction where the volume of communication is low and the calling party needs a result to continue, for instance, user interaction

I think most proponents of concurrent modeling techniques will tell you they don't need to have synchronous communication in their technique because they can emulate it. For instance, this

is how you express a synchronous call in the Petri-net based process modeling tool I used to work on. As you can see, the circles represent states or conditions, but also data items, while the squares represent state transitions. Control flow and data flow are both expressed, but not distinguished within the modeling technique. But this is unusual: techniques based on communicating state machines do separate state changes (within the machines) from event/data passing (between the machines).

Furthermore, there's a movement in systems design and programming that says to avoid synchronous communication in the first place. Systems should be concurrent and event-based by design, all the waiting for replies on synchronous calls just holds up your components for no other reason than your own ineptness at design, synchronous calls are just mental laziness induced by having looked at inherently sequential systems for too long. This approach to interactive applications has gained a lot of traction in recent years.

So many people in this area will say you don't need separate modeling constructs for user interaction: a user input and output to the user are just communications, flowing on communication channels between two system components, one of which is the user. It's message passing and all you need is a message passing formalism.

An alternative to modeling I/O as messages within the system is to model inputs and outputs as properties of state transitions. For instance, this is done in Mealy machines and I/O automata. This is used for model-based testing: the expected behavior of the system is modelled using an I/O automaton and used to generate test cases that are then used to verify whether the actual system meets the specifications. This approach is really focused on interactive systems, not flow-based systems.

So there are many approaches to choose from; none of them can be said to be canonical, but approaches based on some form of state machines are the most popular, so if you'd insist on calling anything canonical, I'd say it's the state machine.