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.


Process Modeling with dPNs

A simple, yet powerful way to model process architecture is using the dualistic extension of Petri nets called dualistic Petri nets (dPNs).[1] 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[2] 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.

Architecture

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

Bottom-Up: Starting with the manifested process

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.

A typical use of reverse engineering using dPNs in the business world is in the documentation of processes for quality certification against standards like ISO 9000. In this case, dPNs are used to model pieces of the business process, which are then combined to form an overall enterprise architecture. The process system can be studied to determine each piece's capability and show where risks occur. Requirements are then reverse-engineered and applied at corresponding dPN constructs. Trouble spot processes can be identified and slated for reengineering. The overall dPN map not only gives quality entities the necessary information about a business's current process, but it also gives the process architect a blue print from which to manage and improve said processes. This is a major portion of quality engineering.

Top-down: From Idea to Implementation

dPN modeling of a new process system starts at a high level of hierarchical abstraction. To design a complex process system, such as a sophisticated hardware component or a major project, the process architect must first define the problem space. Since the problem space is itself a process system, dPNs can be used for its modeling. Abstract dPNs that are yet to be implemented are specified within the context of the problem space. These constructs define the solution space within its context network. It is now up to the process architect to traverse down the hierarchical abstraction dimension, proposing new process designs for the solution space in an iterative manner until specifying the actual implementation in the specific implementation language.

This method for designing a complex process system is reflected in the general software development methodology known as the waterfall model. Actually, this method is not well-suited for the development of complex software without adjusting it to handle the step-wise decomposition of the process architecture. This decomposition occurs entirely within the domain of dPNs from the problem space context model down to the final mapping of the implementation language.

Process Structure

Whether a dPN hierarchical network map was created from the bottom up or from the top down, it shows the structure of the process system. Complex process systems, such as large computer programs, will have several layers of hierarchical abstraction. At the top of the structure is one process represented by a couple of dPN constructs. Each subsequent layer below this process is the decomposition of the dPN constructs made up of more dPNs that are in turn decomposed. The “parent” dPN of a set of decomposed dPNs has associated with it requirements that apply to the decomposed network. These requirements were determined by studying the parent dPN's suprastructure or the hierarchical structure above the construct. The decomposed “children” dPNs form the infrastructure or the hierarchical structure below the parent dPN.

In complex computer design, requirements are generated and infrastructures proposed. Chosen infrastructures are then further decomposed by determining the new constructs' requirements and decomposing them further in this iterative fashion until the dPNs are decomposed into the implementation language of software or hardware specification. The final hierarchical dPN map documents the architectural decisions that were accepted and a specification is in place that can be used to maintain the system's future evolution.

In business processes, process requirements are policies that must be fulfilled by acceptable procedures. Complex procedures can be specified by simpler procedures. Since business processes are processes, dPNs are an ideal modeling language for them – especially when considering complex business processes like logistics.

Conclusion

The entire network of dualistic Petri nets becomes the architecture specification of the process system. If the problem and solution space are entirely in software, it is known as software architecture. If the problem and solution space are business processes, it is known as enterprise architecture. If the problem and solution space are networked equipment, it is known as network architecture. What is important to each of these applications and to any other process system of varying complexity is that the hierarchical map of the system's structure created by the network of dPNs allows the process architect to study the behavior and performance of the system, keeps architectural design decisions documented, and organizes process requirements along the architectural structure.

See also

References

  1. ↑ Dawis, E. P., J. F. Dawis, Wei-Pin Koo (2001). Architecture of Computer-based Systems using Dualistic Petri Nets. Systems, Man, and Cybernetics, 2001 IEEE International Conference on Volume 3, 2001 Page(s):1554 - 1558 vol.3
  2. ↑ Dawis, E. P. (2001). Architecture of an SS7 Protocol Stack on a Broadband Switch Platform using Dualistic Petri Nets. Communications, Computers and signal Processing, 2001. PACRIM. 2001 IEEE Pacific Rim Conference on Volume 1, 2001 Page(s):323 - 326 vol.1
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.