UMLの単一ブランチの「結合ノード」と「フォークノード」
UML仕様のセクション15.3.3.3は次のように述べています。
フォークノード
ForkNodeは、フローを複数の並行フローに分割するControlNodeです。
また、15.3.3.4さんのコメント：
ノードに参加
JoinNodeは、複数のフローを同期するControlNodeです。
また、15.3.4.2さんのコメント：
ノードの分岐と結合
[...] ForkNodeには単一の着信ActivityEdgeが必要であり、通常には2つ以上の発信ActivityEdgeがありますが、JoinNode 通常には2つ以上の着信ActivityEdgeがあり、単一でなければなりません発信ActivityEdge。
したがって、仕様は次のように述べています。「fork node tosplit single flow to a single flowand join node to synchronize単一のフロー。 "しかし、concurrencyとsynchronizingの概念の意味に注意すると、それは合理的ではなく、意味もないと思います。私は何かを誤解していますか？はいの場合、fork nodeとjoin nodeをそのように使用する必要がある例はありますか？
要するに
あなたは正しく理解しました。
長い間
標準の分析
15.3.3.3はそれを非常にはっきりと言っています：
ForkNodeは、フローを複数の並行フローに分割するControlNodeです。 複数の出力がある場合があります ActivityEdgesですが、ForkNodeには1つの入力ActivityEdgeがあります。
ここで重要なのは、不整合が発生するため、ForkNodeが発信アクティビティEdgeを持たないことです。そのようなナンセンスが可能である場合、トークンの流れは中断されますが、それは決して終わりません。部分フローを終了する場合は、FlowFinalNodeを使用する必要があります。
ForkNodeに出力が1つしかない場合は、あまり役に立ちません。ただし、それによって矛盾が生じることはありません。
|
----->|-----> is equivalent to ---------->
|
同様に、15.3.3.4は全体像を示します。
JoinNodeは、複数のフローを同期するControlNodeです。 JoinNodeには1つの発信ActivityEdgeがありますが、複数の着信がある場合があります ActivityEdgesです。
推論は以前と同じです。少なくとも1つの入力があることが重要です。複数あることが予想されますが、1つしかない場合でも、矛盾は発生しません。
同じセクションの次の文は、andには2つのオペランドが必要であるため、複数の入力が期待値であることも示しています。ただし、プレーンテキストでの再構成により、1つの入力のみで機能します。
JoinNodeにjoinSpecがない場合、これはブール演算子“ and。”を使用したjoinSpec式と同等です。つまり、暗黙的なデフォルトのjoinSpec条件は、少なくとも1つのトークンが各着信ActivityEdge。
単一の入力を使用した結合には、joinSpecの作成方法に応じて、特に入力がObjectFlowである場合、いくつかの目的があることに注意してください。
表現力
フォークへの出力が1つだけであっても、同時実行性には実質的な影響はありません（唯一のフローはそれ自体と並行しています）。これを信じられない場合は、少なくとも開始ノードが1つしかないこと以上の効果はないであることに同意する必要があります。15.3.3.1は、
アクティビティに複数のInitialNodeがある場合、アクティビティを呼び出すと、各InitialNodeに1つずつ、複数の同時制御フローが開始されます。
UMLがモデラーが一貫して何かを表現できるようにするという事実は、このことが有用であることを意味しません。たとえば、UMLでは、終了ノードへのフローを持つ開始ノードのみでアクティビティ図を作成できます。活動は何もしないことからなると言うためのもう一つの手の込んだ方法。
ジョインの入力が1つだけか、フォークの出力が1つだけの可能性は、セマンティクスに影響を与えずに、表現力の点でいくつかの利点があります。この種の構成を使用することにより：
- これはモデルの部分図であることを強調できます。アクティビティモデルの一部が表されていないか、まだ設計する必要があることを理解してください。
- また、将来、フォークとジョインの間である程度の並行性が期待できることを示唆することもできます。
- 一連のアクションを視覚的に分離できます