UML2アクティビティ図でControlFlowとObjectFlowをマージするにはどうすればよいですか？
15.3.3.5 OMG®Unified ModelingLanguage®（OMGUML®）バージョン2.5.1
MergeNodeの発信エッジがControlFlowである場合、すべての着信エッジはControlFlowsである必要があり、発信エッジがObjectFlowである場合、すべての着信エッジはObjectFlowsである必要があります。
ここに図があります：
その意図は、かつては継続的に開始されていた注文記録と貿易記録を受け取り、処理するプロセスをモデル化することでした。停止要求を受信するとすぐに、プロセスは停止します。
ノード[〜＃〜] a [〜＃〜]および[〜＃〜] b [〜＃ 〜]は、すべてのフローがObjectFlowであるため、問題ありません。 [〜＃〜] c [〜＃〜]および[〜＃〜] d [〜とマークされたノード＃〜]は、InitialNodesからのフローがControlFlowsであるため問題があります。
15.2.3.6アクティビティの実行によると、最初にTrade Record ReceivedノードとOrder Record Receivedノードを有効にするために、InitialNodeからのフローが必要です。
アクティビティが最初に呼び出されたとき、入力ActivityParameterNodes以外のそのノードのいずれも最初はトークンを保持しません。ただし、入力エッジがなく、実行に入力データを必要としないノードはすぐに有効になります。
したがって、アクティビティが最初に呼び出されたときにStop Request Receivedが有効になり、Trade Record ReceivedおよびOrder Record Receivedは有効になりません。
この図をUML仕様に準拠させる方法はありますか？
isControlType=trueトレードレコード、ストップリクエスト、オーダーレコードの各ピンは、15.4.3.1のオブジェクトノードに従って、すべてのフローがControlFlowsになることを意味します。
isControlType=trueObjectNodeの場合、ControlFlowはObjectNodeとの間で送受信され、オブジェクトトークンはControlFlowに沿ってObjectNodeに出入りすることができ、これらのトークンはObjectNodeの下流に到達したControlFlowに沿って流れることができます。このようなオブジェクトトークンの値は、このようなControlFlowsのターゲットであるExecutableNodesの制御に影響を与えるために使用できますが、このような値の具体的な意味はこの仕様では定義されていません
最後に、OMG®Unified ModelingLanguage®（OMGUML®）バージョン2.5.1のドキュメントで答えを見つけました。
16.10.3.1のAccept Event Actionの条項は、最終的に次のように述べています。
...入力エッジのないAcceptEventActionは、イベントの発生を受け入れた後も有効のままです。つまり、イベントの発生を受け入れて値を出力した後は終了しませんが、別のイベントの発生を待機し続けます。
したがって、ノードCおよびD（その唯一の目的は、Trade Record ReceivedおよびOrder Record Receivedを再度有効にすることです）は必要ありません。
多くの方法がローマにつながります。だからここに私が何をするかです：
2つのアクションは並行して開始されます（フォークの後）。取引と注文には2つのキュー（データストア）があります。それらはどこか他の場所で満たされ、利用可能な注文または取引はイベントを介して通知されます。アクションはこれらのシグナルに反応し、次の注文/取引をポップして処理します。これで、オブジェクトは割り込み可能な領域の外に流れ、注文/取引を処理できます。その領域に戻った後、受信した停止はプロセス全体を終了します。
トランザクションのセキュリティはデリケートであることに注意してください。実装の詳細（セマフォが必要になる可能性が高い）は、SDを使用した設計スケッチでより適切に表示されます。しかし、ADはある種のビジネス概要を提供することを目的としています。
フォークで単一の開始ノードを使用するのではなく、2つの別々の開始ノードを使用して、左/右のマージノードに行くことができます。その可能性を知りませんでした。