web-dev-qa-db-ja.com

UMLのアクティビティ図で「待機」を表す

以下のUMLアクティビティ図で「顧客担当者が対応可能になるまで待機する」を表すにはどうすればよいですか？ UML 1またはUML 2のソリューションはどちらも受け入れ可能です。

提案1

wait state model

2番目の条件に戻る単純な行は、「見た目」が間違っています。

提案2

私はこの「よりクリーンな」ソリューションも思いつきました。

enter image description here

（最後の点が欠けていることは知っています。）

umlactivity
7
problemofficer

私見、実際には「待機」状態の条件付きループや「ループ」を含める必要はまったくありません。

Activitive_Example

アクティビティが完了するまでには、一定の時間が必要です。顧客担当者がすぐに対応できる場合、待機アクティビティの時間はゼロです。それがない場合、アクティビティは数分または数時間かかるだけです。しかし、「ゼロ」の威力は、人為的な区別を必要とせずに、他の数値と同じように処理できることが多いことです。

もちろん、「待機」アクティビティを明示的にモデル化する場合、システムでは「実際の待機」中に本質的に異なる何かが発生するため、ソリューション2を使用します。

10
Doc Brown

あなたの図は大丈夫ですか？

決定ノードのガードは、ノードではなくラインのテールに配置する必要があります（UML 2.5セクション15.2.4を参照）。したがって、ダイヤの上部にある_[free customer representative available]_は削除され、送信される_[yes]_および_[no]_は_[customer representative available]_および_[customer representative not available]_に変更されます。

この後、両方の図で正式に問題はなくなります。

  • プロポーザル2は、waitアクティビティが完了したときに顧客担当者が対応できることが保証されている場合にのみ、期待される結果を生成します。これは明白ではないので、左に分岐し、マージダイヤモンドを決定ダイヤモンドの前に置き、代表者が利用可能になるまで続行しないようにします。

  • 提案1は完全に正しいです。アクティビティ図の制御ノードは、いくつかの出力フローを持つ決定ノード、またはいくつかの入力フローを持つマージノード（UML 2.5セクション15.3.2を参照）ですが、幸い、両方とも図で単一のひし形にまとめることができます（セクション15.3.4.3のUML 2.5図15.34を参照）。ただし、個別のノードよりも読みにくくなります。

  • あなたはすでに知っていますが、orderの後に終了ノードが必要になります。

しかし、それは本当に最善の方法ですか？

ダイアグラムは、アクティビティwait (for representative)に対する人間の理解に依存しています。しかし、待つことは実際には活動ではなく、活動ではないことに同意します。

代替1：_Customer representative available_と呼ばれる accept-event-action の助けを借りて、イベント駆動型アプローチを使用しますあなたが待っているものを表しています。そこから出てくる流れを通常の流れとマージします。注意：魅力的なTimeEvent（砂時計の記号）は使用しないでください：特定の時点で発生するイベントを対象としています（UML 2.5セクション13.4.10.1を参照）

代替案2：は、あなたが実際に何をしているのかを表しています。つまり、顧客の代表を探しています。これはそれを示すための簡単な方法です。

enter image description here

代替3（私のお気に入り）：は、マルチタスクの世界の真の複雑さを表します フォークと結合コントロール =、そして並行して起こっているすべての間に：

enter image description here

4
Christophe

スイムレーンを使用する場合、待機メカニズムは必要ないと思います。顧客担当者がタスクを実行する準備ができている必要があることを意味しています。

PlantUML/PlantText での提案を次に示します。

enter image description here

[〜＃〜] edit [〜＃〜]次に、より明示的な待機セマンティクスを使用した別の提案（ source ）を示します。電話を切るため。

enter image description here

1
Fuhrmanator

「待機」状態、または待機アクティビティがあることは信じられないことではなく、ドメインによっては珍しくもありません。それをそのようにマークし、状態がアクティブである期間（つまり、決定ポイントに戻るまでの期間）を定義します。

デシジョンポイントを明示的に公開する必要がない場合は、決定と待機状態を1つのアクティビティにまとめて、オペレーターの可用性に移動できます。

余談ですが; OPがプロジェクトで評価されている実際のフローの「デモ」である場合、モデルやこの動作をモデル化するための、調査する価値のある他のオプションがあります。

  • FSM、マシンを「注文する」状態に移行させるイベントがある状態
  • 同期が必要なフローが複数ある場合は、結合の方が適している可能性があります

他のソリューションは、別のモデルである場合や、待機状態を削除する何らかの再設計である場合があります。とは言っても、モデル化されているプロセスフローの動作であるため、ソリューションは単なる待機状態であることがよくあります（これは、設計によるか、分析によるか）。

追加された2番目のオプションでは、「待機」は本質的に、必要な条件が満たされているかどうかを判断するためのテストが必要です。2番目のオプションが適切にモデル化されているかどうかはわかりません。

1
Niall

コンサルタントの準備ができているシグナルの受信を表すには、ReceiveSignalActionを使用する必要があります。

申し訳ありませんが、現時点で利用できるモデリングツールはありません。コンピュータに座ったら図を追加します。

0
Ister