プロセスデータ図

プロセスデータ図（PDD）はプロセス成果物図とも呼ばれ、プロセスとこれらのプロセスの出力として機能するデータを記述する図です。左側にはメタプロセスモデルが表示され、右側にはメタデータモデルが表示されます。^[1]

プロセス データ ダイアグラムは、ビジネス プロセス モデルとデータ モデルの組み合わせとして考えることができます。

右側に示されているプロセス データ図は、これらすべてのアクティビティ/プロセスと成果物の概要を示しています。4 つの灰色のボックスは、4 つの主要な実装フェーズを示しています。各フェーズには、この場合はすべて連続する複数のプロセスが含まれています。右側のボックスには、プロセスから得られる成果物/概念がすべて表示されています。影のないボックスには、それ以上のサブ概念はありません。黒い影の付いたボックスは、複雑で閉じた概念、つまりサブ概念を持つ概念を表しますが、これ以上詳しく説明しません。白い影の付いたボックス (その背後にボックスがある) は、開いた閉じた概念を表し、サブ概念がより詳細に展開されています。ひし形の線は、概念間の has-a 関係を示しています。

SAP 実装プロセスは、SAP ソリューションの将来のビジョンを作成するプロジェクト準備フェーズ、ソフトウェア スタックを取得してトレーニングを実行するサイジングおよびブループリント作成フェーズ、機能開発フェーズ、そして実際の稼働前に最後のテストを実行する最終準備フェーズという 4 つの主要なフェーズから構成されています。各フェーズでは、重要なアクティビティが取り上げられ、成果物/製品が説明されます。

シーケンシャル アクティビティは、事前に定義された順序で実行する必要があるアクティビティです。アクティビティは矢印で接続されており、その順序で実行する必要があることを示しています。アクティビティとサブアクティビティは両方とも、シーケンシャルな方法でモデル化できます。図 1 では、1 つのアクティビティと 2 つのシーケンシャル サブアクティビティを含むアクティビティ図が示されています。特殊な種類のシーケンシャル アクティビティは、開始状態と停止状態であり、これも図 1 に示されています。

図 2 に、実際の例を示します。この例は、UML ベースの Web エンジニアリングにおける要件キャプチャ ワークフローから取られています。主なアクティビティであるユーザーとドメインのモデリングは、事前に定義された順序で実行する必要がある 3 つのアクティビティで構成されています。

• 
  1: 連続したアクティビティ
• 
  2: 例
• 
  3: 順序のないアクティビティ
• 
  4: 例

順序なしアクティビティは、アクティビティのサブアクティビティに実行する必要がある事前定義された順序がない場合に使用されます。順序なしとすることができるのはサブアクティビティのみです。順序なしアクティビティは、図 3 に示すように、アクティビティ内で遷移のないサブアクティビティとして表されます。

アクティビティは、順次サブアクティビティと順序なしサブアクティビティの両方から構成されることがあります。このモデリングの問題の解決策は、メイン アクティビティを複数の部分に分割することです。図 4 に、順序なしアクティビティをモデル化できる必要性を明確にする例を示します。この例は、Unified Process の要件分析ワークフローから取られています。メイン アクティビティ「候補要件の説明」は、2 つの部分に分かれています。最初の部分は順次アクティビティです。2 番目の部分は、正しく実行するために順序を必要としない 4 つのアクティビティで構成されています。

アクティビティは同時に発生することがあります。これは、フォークと結合によって処理されます。図の中でアクティビティを並行に描画し、同期バーで接続すると、複数のアクティビティをフォークできます。後で、これらの同時アクティビティを同じ同期バーを使用して再び結合できます。アクティビティとサブアクティビティの両方が同時に発生することがあります。図 5 の例では、アクティビティ 2 とアクティビティ 3 が同時アクティビティです。

図 6 には、要件キャプチャ プロセスの一部が示されています。アクターの定義とユース ケースの定義という 2 つのアクティビティが同時に実行されます。これらのアクティビティを同時に実行する理由は、アクターの定義がユース ケースに大きな影響を与え、その逆も同様であるためです。

• 
  5: 同時活動
• 
  6: 例
• 
  7: 条件付きアクティビティ
• 
  8: 例

条件付きアクティビティは、事前に定義された条件が満たされた場合にのみ実行されるアクティビティです。これは、ブランチを使用してグラフィカルに表現されます。ブランチはダイヤモンドで示され、入力遷移と出力遷移を持つことができます。すべての出力遷移には、ガード式、つまり条件があります。このガード式は実際にはブール式であり、進む方向を選択するために使用されます。アクティビティとサブアクティビティの両方を条件付きアクティビティとしてモデル化できます。図 7 には、2 つの条件付きアクティビティが示されています。

図 8 に、実際の例を示します。要件分析は、資料の調査から始まります。この調査に基づいて、広範な要件抽出セッションを実行するかどうかが決定されます。この要件セッションを実行しない条件は、ブランチの左側、つまり [要件クリア] に示されています。この条件が満たされない場合は、[else] で、もう一方の矢印に進みます。

両方のタイプの図の統合は非常に簡単です。各アクションまたはアクティビティは概念を生み出します。図 9 に示すように、それらは生成された成果物に点線の矢印で接続されています。この図では、概念とアクティビティは抽象的です。

表 1 には、アクティビティ、サブアクティビティ、およびそれらの概念との関係を説明した一般的な表が示されています。セクション 5 では、プロセス データ図とアクティビティ テーブルの両方の例が示されています。

表1: アクティビティ表

図10はプロセスデータ図の例です。これはWebエンジニアリング手法における複雑なプロジェクトのオリエンテーションフェーズの例です。^[1]

注目すべきは、オープン コンセプトとクローズド コンセプトの使用です。プロジェクト管理は実際にはこの研究の範囲外であるため、コントロール管理の概念は拡張されていません。ただし、複雑なプロジェクトでは、リスク管理が非常に重要です。したがって、リスク管理の概念を拡張することを選択しました。

表 2 では、アクティビティとサブアクティビティ、および概念との関係について説明します。

表2: 複合オリエンテーションフェーズにおけるアクティビティとサブアクティビティ

ウィキメディア・コモンズには、プロセスデータ図に関連するメディアがあります。

• 買収開始 (ISPL)
• 変更管理（エンジニアリング）
• 動的システム開発手法
• ITIL セキュリティ管理
• 実装成熟度モデル評価
• ステージ境界の管理
• メタデータモデリング
• オブジェクトプロセス方法論
• プレビュー
• 製品ファミリーエンジニアリング
• 製品構造モデリング
• 同期モデル