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==