Benefit of Petri Net Transition as Separate Object

In learning about Timed Automata, Coloured Petri Nets, and Process Calculi, I am wondering what the benefit is of having the Petri Net transition be a separate type of node in Petri Nets.

It seems that you can model the same stuff (eventually) using Timed Automata or Process Calculi, which both only have states and transitions (as edges, not objects). Instead of transition nodes, you could just have two types of "state", one be the Petri net place, the other be the Petri net transition. Then this second node does all it's queuing/guarding/checking of the tokens and whatnot. So I'm not sure the benefit is of having transition be a separate object in Petri Nets, when it could just be a second kind of "place" or "state".

That makes me wonder if there is a generalization of Petri nets to arbitrary number of node types (where instead of just place/transition, you have x, y, z, ...). In this sense it seems that process calculi are a generalization of Petri Nets.

In my experience, the duality of Petri nets is a great strength.

It forces us to specify the potential events or actions in a system (the transitions), as they may happen to individual items (the tokens), together with their preconditions and postconditions (the places). This forces us to think through what a step really means as we're denoting it, because we're denoting its effects as well.

When done right, it also matches a natural language specification. In a natural model, transitions represent predicates involving verbs of change, places represent predicates involving verbs of state, and tokens represent their subjects. For instance:

• a transition can be a customer arrives, or switch the light off, or the light breaks, or the sun goes down;

• a place can be a customer is waiting, or a customer is ready to pay, or the light is off, or the sun is down;

• a token is a customer, the light, the sun.

(Further expanded in this answer.)

It greatly helps to adopt this as a naming convention for your Petri nets. You can then read the model out loud as a bunch of natural statements in natural language.

Let's compare this to models without this duality.

On one hand, we have state machine based models.

These list the system's states and connect them with arrows representing state transitions. Such a model can only be in one state at once; it does not allow the specification of individual conditions that together specify the global state, like places in a Petri net do. Of course we can draw several state machines for several subsystems and say they somehow operate together, and we can add that into the modeling technique by adding ways of specifying how submodels combine and coordinate; in Petri nets, we don't need to do that, the ability is already there. Moreover, if we want to start describing a system we don't already know, or design a system that doesn't already exist, writing down a bunch of predicates describing the relevant conditions and potential changes, like we can when specifying Petri nets, feels more natural to me, and leaves more freedom, than having to write down a specification in terms of state machines.

(That being said, when state-machine based techniques and Petri nets are extended to support modelling arbitrary processes in detail, the results may be very similar. Abstract State Machines look quite similar to algebraic Petri nets.)

On the other hand, we have process models in which the objects are steps to be taken, connected with arrows to describe the order in which they (may) happen. In my opinion, these are awful and a hindrance to good process design.

The simplest kind I've seen is just a bunch of boxes and arrows, like this:

What does this say? After we go home, do we both feed the cat and get a glass of water? Do we choose between them? Does it vary? We have no idea. This is not a specification, it's a sketch.

Then, of course, we have flowcharts. Flowcharts, like state machines, describe completely sequential processes. Starting in the initial state, each box in the flowchart takes us to the next state, until we reach the final state. The two examples in Wikipedia:

The boxes are actions; the diamonds are tests, which pick the next step based on the test result. An imperative computer works this way, and so do many completely sequential algorithms executed by something other than a computer. Flowcharts can describe them, but they are of little help in reasoning about them: in designing them, redesigning them, or proving their correctness.

A flowchart models the actions that change certain conditions, and tests that inspect certain conditions, but it doesn't model the conditions themselves. To prove correctness, we must explicitly model all of the relevant conditions, state which conditions must hold at the start, state which conditions must hold at the end, and by bookkeeping the conditions along the way, prove whether or not the algorithm is guaranteed to achieve that.

This is exactly what proof techniques for correctness of algorithms do (e.g. Hoare logic) and it will happen when turning a flowchart into a Petri net. The places will specify the relevant conditions.

So one limitation of flowcharts is that, by omitting bookkeeping on the relevant conditions, they don't support reasoning about the algorithms being specified. But at least they can specify such algorithms. Things get much worse when the algorithm in question isn't already given.

How do you design an algorithm for a given problem from scratch? You specify the initial and final conditions and you figure out a bunch of intermediate conditions and steps to bridge that gap. The designer must be explicit about the intermediate steps and how they affect the intermediate conditions. This is not usually a linear process in which the designer specifies all steps one by one from start to finish; rather, it tends to be a more unstructured refinement and reshuffling process. The exact order in which things are done

StackExchange Computer Science Q#92712, answer score: 2