アクティビティチャートを構築する2つのアプローチ

アクティビティ図を構築するための2つのアプローチの比較（「タンパク質」に基づく）

「プロセスモデリングから自動化システムの設計まで」の記事の最初の部分では、「おとぎ話」の主題領域のプロセスをシミュレートしました-「テサルサルタンの物語、彼の栄光と力強い英雄プリンスグヴィドンサルタノヴィッチと美しい白鳥の王女」からのリスA.S.プーシキン。 そして、アクティビティ図から始め、「水泳」パス（スイムレーン）を使用して図のフィールドを構造化することに同意しました。 トラックの名前は、このトラックに存在するチャート要素のタイプに対応します：「入力および出力アーティファクト」、「プロセスステップ」、「参加者」、および「ビジネスルール」。 このアプローチは、トラックがプロセスの参加者の名前で示されるため、プロセスの特定の責任領域を割り当てられるという点で標準とは異なります。

この例では、オーストラリアの会社Sparx Systems [1]のEnterprise Architect環境を使用しています。

適用されたモデリング手法の詳細については、[2]を参照してください。

ここで完全なUML仕様を参照してください[3]。

前の記事（図1）の図のバージョンを繰り返し、「標準」トラックで再描画された図（図2）を表示し、賛否両論の概要を少し主観的に説明します。

図1.アクティビティ図-プロセスの全体図

図2.アクティビティ図-標準的なチャート構造

1. 2番目の図では矢印の数がわずかに少ないことを認めなければなりません。
2. しかし、2番目のダイアグラムでは、オブジェクトはダイアグラムのフィールド全体に「塗り付けられ」ます。これは、私の好みではあまり便利ではありません。
3. ノートと同じストーリー-ルール。 そして、執事の任命に関する規則を挿入するために、ある時点でダイアグラムのすべての要素を移動する必要がありました。
4. このステップに複数の参加者がいたことを示すために、「受信/送信...」ステップのクローンを作成する必要がありました。
5. 2番目のオプションでは、1つのブランチと1つのプロセスのマージを放棄する必要がありました。まあ、それらを「美しく」配置することは完全に不可能でした。 良い場合は、コメントを投稿する必要があります-ルール。

もちろん、味と色の友人はいませんが、最初のオプションは、プロセスに関するデータを収集するのにさらに便利なようです。

しかし、私は解体しません-時にはそれを理解するために両方のオプションを描くほうが良いです。

追加。 コメントをありがとう、2番目のオプションの図を少し修正してください：トラックを再配置できます（図2では、そのシーケンスがストーリーの参加者のシーケンスを繰り返します）、交差する矢印の数がわずかに減少します（図3）。

図3.アクティビティ図-標準的なチャート構造-再配置されたトラック

この記事の登場に基づいた記事：

プロセスモデリングから自動化システムの設計まで（パート1）

プロセスモデリングから自動化システムの設計まで（パート2）