まず、ユースケース図は実際の (書かれた) ユースケースの代わりになるものではないことを認識しておく必要があります。ユース ケースの説明には、ユース ケース図では省略されている多くの重要な詳細が含まれています。ユース ケース図は、アクターの階層、関連付けられたユース ケース、およびユース ケース間の関係を表すのに適していますが、それ以上のものではありません。
もう1つの重要なことは、ユースケースが実際に何であるかを理解することです。それらについて考える良い方法は、システムの助けを借りて達成したいアクターの目標を見つけることです。この目標を達成することは、アクターに何らかのビジネス価値を与えるはずです。私のポイントは、あなたが説明したことから、登録ユーザーは観光を検索したり、入場券を購入したりする可能性があるということです。したがって、これが彼の目標であり、これはユースケースであるべきです。ユースケースを、さまざまな検索方法などの機能/機能と混同しないでください.
最初の提案では、データのみが異なる 2 つのユース ケースがあります (たとえば、フォームのコンボ ボックスとは異なる選択肢である可能性があります)。このような違いは、システムとアクターの対話方法に影響しない場合は、ユース ケースで参照するデータ用語集のユース ケースとは別に説明されています。このようにして、ユースケースの説明で多くの不要な詳細を避けることができます。一方、説明の手順が変更された場合 (たとえば、登録ユーザーが場所システムを選択すると、別の登録ユーザーを友人として選択し、両方のお気に入りの場所を事前に選択するか、そのようなものを選択するオプションが与えられます...) 、代替/拡張機能を使用してこれをキャプチャできます。
あなたは、開発中のシステムを二次的なアクターとして言及しています。開発中のシステムは暗黙のアクターであり、別のアクターとして図に示されているわけではないことを忘れないでください。境界ボックス (アクターを除くユース ケースを囲む四角形) を使用して、システムの範囲を示します。
最後に気になるところ。これらはすべてデータに関する詳細であり、ユース ケースの一部ではありません。上記のデータ用語集を使用して、これらの詳細をテキストでキャプチャできます (すべてのカテゴリに名前を付けるなど)。データ間の構造と関係が重要であり、図を使用して把握する必要があると思われる場合は、クラス図を使用してデータ/ドメイン モデルを作成できます。
ユースケースの関係に関する最後の注意 - 必要がない場合は使用しないでください。多くの場合、それらは理解しにくく、あいまいに定義されています。機能を分解するためにそれらを使用しないでください。これは、ユースケースによる分析ではなく、設計次第です。