UMLで「選択動作」はどのように機能しますか？
_selection behavior_ sの_object flow_の例と使用法について2時間読んだり検索したりした後、基準（クエリなど）を満たすall tokensを選択すると、これは変更される可能性があります_15.2.3.4 Object Flows_の仕様としてのトークンの順序は次のとおりです。
選択動作が指定されている場合は、ObjectNodeの順序を使用するのではなく、ソースObjectNodeからObjectFlowにトークンを提供するために使用されます。
しかし、上記のセクションは言う：
ObjectFlowに新しいトークンが提供されるか、オファーが撤回されると、Behavior入力パラメーターに渡されたObjectFlowに現在提供されているすべてのオブジェクトトークンからの値を使用して、選択動作が呼び出されます。次に、選択動作は入力値の1つ選択で、出力として生成されます。
私が2番目の引用から理解することは：
- 新しいトークンが提供されたとき、またはオファーが撤回されたときにのみ呼び出されます（以前に保存されたトークンが受け入れられたときは呼び出されません）
- 複数のトークンが格納されている場合、それ以上のトークンがあってもは、1つのトークンのみを選択します（条件を満たすすべてのトークンではなく）条件を満たすもの。たとえば、この状況では1つの候補のみが受け入れられます。
上記の箇条書きは本当ですか？（私はそれらが間違っていると思いますが、それらは私の2番目の引用の理解です）また、2番目の引用の_offer is withdrawn_の意味は何ですか？
"selection"は、ObjectFlowのトークンを制限したり、トークンの順序を変更したりできるセマンティクスを導入します。したがって、両方のケースを念頭に置いて、仕様を読んでください。
この標準は、図15.16に、"selection"を使用して、提供されたOrdersを優先順に出荷するように指定する例を示しています。
あなたの最初の弾丸は正しいです。保存されたトークンについては何も言われていません。そして、私たちは気にする必要はありません。発送注文の例を見てみましょう。選択基準に一致するOrderトークンのセットが待機していると仮定します。配送が新しいOrderを消費する場合、選択により、提供されたトークンの優先度が最も高いことを確認する必要があります。すでに受け入れられているOrdersがソートされた方法で保持されている（オファリングで行われる可能性がある）か、消費時に注文されているかはわかりません。
2番目の箇条書きは正しくありません。選択動作は、その出力に対して1つのトークンのみを選択します。つまり、1つずつ提供されます。他が捨てられるとは言わない。したがって、あなたの例では、いくつかの候補者が基準に一致する場合、それらすべてが面接されます。標準の解釈が想像どおりに限定的である場合、モデル化されたシステムは優先度順ではなく各束の最高優先度のみで出荷するため、注文出荷の例は機能しません。