Dualistic Petri nets

Dualistic Petri nets (dPNs) are a process-class variant of Petri nets. Like Petri nets in general and many related formalisms and notations, they are used to describe and analyze process architecture.

A simple, yet powerful way to model process architecture is using the dualistic extension of Petri nets called dualistic Petri nets (dPNs). A Petri net (PN) is a graphical, bipartite modeling language that intuitively and mathematically represent theoretical relationships of moving objects in a network of interconnected constructs. Classical Place/Transition PNs can represent theoretical processes, where the movement of objects implies their transformation, but is too absolute to be pragmatic in representing real-world processes. The real world is dualistic in nature and process is a dualistic phenomenon, this can not be easily represented using a digital-type modeling system. Instead, dualistic extensions to Place/Transition PNs have been introduced and used successfully in modeling the architecture of computer-based systems and business processes.

Among the distinctions of dPNs from classical PNs is space and time (due to energy use) in both the place construct and transformation construct. This results in the simulation effect of marked transformations that allow for the explicit representation of parallel processing, multiprocessing, and the implicit representation of deterioration of objects – all unique to dualistic Petri nets.

Besides a propensity to modeling dualistic real-world behavior, PNs also offer a way to manage complex process systems hierarchically. Using classical PN construction rules, Petri nets of Petri nets can be built and a hierarchical conception of a complex process system can be studied. This structure of hierarchical abstraction is the heart of process architecture!

Dualistic Petri nets are capable of modeling any process system at its manifested level. When reverse engineering a manifested process, dPNs have a one-to-one correspondence of dPN construct to any manifested process piece, that is, it is isomorphic to the implementation language of the manifested process. For example, several lines of software code could be represented by one dPN transformation construct. Once the manifested process is completely represented by a network of dPNs, small, well-coupled groups of dPN constructs can be lumped together to form higher level dPN constructs – creating a network of dPNs at a higher level of hierarchical abstraction. Each level of abstraction is consistent with its adjacent levels of abstraction and the rules governing them at each level are the exactly the same because PN abstractions are homomorphic. Now the process design can be considered at various levels of abstraction as deemed appropriate by the process architect, allowing for studies in its dynamic behavior and performance.

...
Wikipedia