二元ペトリネット(dPN)は、ペトリネットのプロセスクラス版です。一般的なペトリネットや、関連する多くの形式や表記法と同様に、プロセスアーキテクチャの記述と分析に使用されます。
プロセス アーキテクチャをモデル化するシンプルかつ強力な方法として、ペトリ ネットの双対拡張である双対ペトリ ネット (dPN) があります。[ 1 ] ペトリネット(PN) は、相互接続された構造のネットワーク内の移動するオブジェクトの理論的な関係を直感的かつ数学的に表現するグラフィカルな二部グラフ モデリング 言語です。従来の場所/遷移 PN は、オブジェクトの移動がその変換を意味する理論的なプロセスを表現できますが、現実世界のプロセスを表現するには絶対的すぎるため実用的ではありません。現実世界は本質的に双対的であり、プロセスは双対的な現象であるため、デジタル タイプのモデリング システムを使用して簡単に表現することはできません。代わりに、場所/遷移 PN の双対拡張が導入され、コンピュータ ベース システム[ 2 ]やビジネス プロセスのアーキテクチャのモデリングに成功裏に使用されています。

dPNと従来のPNの大きな違いの一つは、プレース構造と変換構造の両方において、空間と時間(エネルギー消費による)が考慮されている点です。これにより、並列処理、マルチプロセッシングの明示的な表現、およびオブジェクトの劣化の暗黙的な表現を可能にする、マーク付き変換のシミュレーション効果が得られます。これらはすべて、デュアルスティックペトリネットに特有の機能です。
ペトリネット(PN)は、現実世界の二元的な振る舞いをモデル化する傾向があるだけでなく、複雑なプロセスシステムを階層的に管理する方法も提供します。古典的なPN構築規則を用いることで、ペトリネットのペトリネットを構築し、複雑なプロセスシステムの階層的な概念を研究することができます。この階層的抽象化の構造こそが、プロセスアーキテクチャの中核を成すものです。
二元ペトリネットは、あらゆるプロセスシステムをその顕在レベルでモデル化することができます。顕在プロセスをリバースエンジニアリングする場合、dPNは、顕在プロセスのあらゆる部分に対して1対1の対応関係を持ちます。つまり、顕在プロセスの実装言語と同型です。例えば、複数のソフトウェアコード行を1つのdPN変換構造で表現できます。顕在プロセスがdPNのネットワークで完全に表現されると、小さく、かつ密接に結合されたdPN構造のグループをまとめて、より高レベルのdPN構造を形成し、階層的抽象化のより高いレベルでdPNのネットワークを作成できます。各抽象化レベルは、隣接する抽象化レベルと一貫性があり、各レベルでそれらを支配するルールは、PNの抽象化が同型であるため、まったく同じです。これで、プロセス設計は、プロセス設計者が適切と判断したさまざまな抽象化レベルで検討できるようになり、その動的な動作とパフォーマンスの研究が可能になります。
ビジネスの世界におけるdPNを用いたリバースエンジニアリングの典型的な用途は、ISO 9000などの規格に準拠した品質認証のためのプロセス文書化です。この場合、dPNはビジネスプロセスの各要素をモデル化するために使用され、それらが組み合わされて全体的なエンタープライズアーキテクチャが形成されます。プロセスシステムを分析することで、各要素の能力を判断し、リスクが発生する箇所を特定できます。次に、要件をリバースエンジニアリングし、対応するdPN構造に適用します。問題のあるプロセスを特定し、再設計の対象とすることができます。全体的なdPNマップは、品質管理部門にビジネスの現在のプロセスに関する必要な情報を提供するだけでなく、プロセスアーキテクトに、当該プロセスを管理および改善するための設計図も提供します。これは品質エンジニアリングの重要な部分です。
新しいプロセスシステムのdPNモデリングは、階層的な抽象化の高レベルから始まります。高度なハードウェアコンポーネントや大規模プロジェクトなど、複雑なプロセスシステムを設計するには、プロセスアーキテクトはまず問題空間を定義する必要があります。問題空間自体がプロセスシステムであるため、dPNを使用してそのモデリングを行うことができます。まだ実装されていない抽象的なdPNは、問題空間のコンテキスト内で指定されます。これらの構成要素は、コンテキストネットワーク内のソリューション空間を定義します。プロセスアーキテクトは、階層的な抽象化の次元をたどり、ソリューション空間に対して反復的に新しいプロセス設計を提案し、最終的に特定の実装言語で実際の実装を指定することになります。
複雑なプロセスシステムを設計するこの方法は、ウォーターフォールモデルとして知られる一般的なソフトウェア開発手法に反映されています。実際には、この方法は、プロセスアーキテクチャの段階的な分解に対応できるように調整しない限り、複雑なソフトウェアの開発には適していません。この分解は、問題空間コンテキストモデルから実装言語の最終マッピングまで、dPNの領域内で完全に実行されます。
dPN階層ネットワークマップがボトムアップで作成されたかトップダウンで作成されたかにかかわらず、それはプロセスシステムの構造を示します。大規模なコンピュータプログラムなどの複雑なプロセスシステムには、複数の階層的抽象化レイヤーがあります。構造の最上位には、2つのdPN構成要素で表される1つのプロセスがあります。このプロセスの下にある各レイヤーは、さらに分解されたdPNで構成されるdPN構成要素の分解です。分解されたdPNのセットの「親」dPNには、分解されたネットワークに適用される要件が関連付けられています。これらの要件は、親dPNの上位構造、つまり構成要素の上位の階層構造を調査することによって決定されます。分解された「子」dPNは、親dPNの下位のインフラストラクチャ、つまり階層構造を形成します。

複雑なコンピュータ設計では、要件が生成され、インフラストラクチャが提案されます。選択されたインフラストラクチャは、新しい構成要素の要件を決定し、それをさらに分解するという反復的なプロセスを経て、dPNがソフトウェアまたはハードウェア仕様の実装言語に分解されるまで、さらに分解されます。最終的な階層型dPNマップは、承認されたアーキテクチャ上の決定事項を文書化したものであり、システムの将来の進化を維持するために使用できる仕様が完成します。
ビジネスプロセスにおいて、プロセス要件とは、許容される手順によって満たされなければならないポリシーのことです。複雑な手順は、より単純な手順によって規定することができます。ビジネスプロセスはプロセスであるため、dPNはそれらをモデル化するのに最適な言語であり、特にロジスティクスのような複雑なビジネスプロセスを検討する際には有効です。
二元ペトリネットのネットワーク全体が、プロセスシステムのアーキテクチャ仕様となります。問題と解決空間が完全にソフトウェアである場合、それはソフトウェアアーキテクチャと呼ばれます。問題と解決空間がビジネスプロセスである場合、それはエンタープライズアーキテクチャと呼ばれます。問題と解決空間がネットワーク機器である場合、それはネットワークアーキテクチャと呼ばれます。これらのアプリケーションおよび複雑さの異なる他のプロセスシステムにとって重要なのは、dPNのネットワークによって作成されたシステム構造の階層マップによって、プロセスアーキテクトがシステムの動作とパフォーマンスを研究し、アーキテクチャ設計の決定を文書化し、アーキテクチャ構造に沿ってプロセス要件を整理できることです。