例：
ユーザーは私たちの店に入り、飲み物を注文することから始めます。私たちは彼に食品をアップセルできます => 食品を購入すると、飲み物も購入できます。
その逆も可能です。ユーザーがサンドイッチを注文したいので、飲み物をアップセルします。=> 飲み物を購入すると、食品を購入できます。
これはこれをモデル化する正しい方法ですか、それとも、飲み物の購入/食品の購入に特化した購入アイテムがある場合は、一般化/専門化を使用する方がよいでしょうか。
それともまだ別の方法で... ?
拡張は決して双方向ではありません (つまり、拡張関係は常に有向です)。
あなたの場合、トーマス・キランが提案したユースケースは1つだけです。
ユースケースを区別することを主張し続ける場合、一般化は良い選択ですが、おそらくあなたのケースでは不要です。
これは非常にまれですが (そして間違いなくあなたのケースではありません)、これがシステムのロジックを表す場合、反対方向の同じユースケース間で 2 つの拡張関係を使用すること (または拡張関係を使用して他の形式のサイクルを構築すること) は禁止されていません。 (たとえば、それぞれが個別に、または開始されたものとして 2 つのうちのいずれかと一緒に処理できる 2 つの別個のエンティティの管理)。実際には、このようなサイクルは (将来の) システム ユーザーとの話し合いで解決できるため、避ける必要があります。一方、インクルード リレーションシップは決してサイクルを作成できません。サイクルが作成された場合、モデルは有効ではありません。
<<extends>>（このように）使用する場合は機能分解を試みています。ユースケースは、システムの機能分解に関するものではなく、考慮中のシステム (SUC) がアクターに提供する独自の付加価値に関するアクションの統合に関するものです。この視点で見てみてください。では、SUC（販売システムだと思います）のユニークな付加価値は何ですか？Sell Goods違いがありSell Food、Sell Drinksそれらが異なる UC であるか、まったくない場合、2 つの UC は必要ありません。