allererst Sie zu erkennen, haben, dass Use Case-Diagramme nicht unbedingt für (geschrieben) Use Cases ersetzen sind. Use Case-Beschreibungen enthalten viele wichtige Details, die in Use Case-Diagrammen weggelassen werden. Use Case-Diagramme eignen sich gut zum Darstellen von Hierarchien von Akteuren, zugehörigen Anwendungsfällen und Beziehungen zwischen Anwendungsfällen, aber nicht mehr.
Eine andere wichtige Sache ist zu erkennen, was ein Anwendungsfall tatsächlich ist. Eine gute Art, darüber nachzudenken, ist, ein Ziel eines Schauspielers zu finden, das er/sie mit Hilfe des Systems erreichen möchte. Das Erreichen dieses Ziels sollte dem Schauspieler einen gewissen geschäftlichen Wert geben. Mein Punkt ist, dass von dem, was Sie beschrieben haben, registrierte Benutzer möchten vielleicht nach einem Sightseeing suchen und/oder Eintrittskarten kaufen. Also das ist sein Ziel und das sollte ein Anwendungsfall sein, nicht Use Cases mit Funktionalität/Features wie verschiedene Arten der Suche usw. zu verwechseln.
In Ihrem ersten Vorschlag haben Sie zwei Anwendungsfälle, die nur in Daten unterscheiden (zB könnte es einfach eine andere Wahl sein als ein Kombinationsfeld in einem Formular). Solche Unterschiede werden, wenn sie die Interaktion von System und Akteuren nicht beeinflussen, getrennt von den Anwendungsfällen in einem Datenglossar beschrieben, auf das Sie in Ihrem Anwendungsfall Bezug nehmen. Auf diese Weise vermeiden Sie viele unnötige Details in Anwendungsfallbeschreibungen. Wenn sich andererseits die Schritte in der Beschreibung ändern (z. B. wenn ein registrierter Benutzer das Ortungssystem wählt, hat er/sie die Möglichkeit, einen anderen registrierten Benutzer als einen Freund auszuwählen und wählt bevorzugte Orte von beiden oder ähnlichem vor ...) , können Sie dies durch Verwendung von Alternativen/Erweiterungen erfassen.
Sie erwähnen das System, das Sie als sekundären Akteur entwickeln. Vergessen Sie nicht, dass das System in der Entwicklung ein impliziter Akteur ist und Diagramme nicht als separater Akteur dargestellt werden. Verwenden Sie das Begrenzungsfeld (Rechteck, das Anwendungsfälle ohne Akteure umfasst), um den Umfang Ihres Systems abzubilden.
Endlich zu Ihrer Sorge. Dies sind alles nur Details zu den Daten, die nicht zu einem Anwendungsfall gehören. Sie können diese Details in Text erfassen (nach allen Kategorien usw.), indem Sie das Datenglossar wie oben erwähnt verwenden.Wenn Sie der Ansicht sind, dass die Struktur und die Beziehungen zwischen Daten wichtig sind und mithilfe von Diagrammen erfasst werden müssen, können Sie mithilfe von Klassendiagrammen Daten-/Domänenmodelle erstellen.
Letzte Anmerkung zu Use Case-Beziehungen - verwenden Sie sie nicht, wenn Sie nicht müssen. Sie sind oft schwer zu verstehen und vage definiert. Verwenden Sie sie nie, um die Funktionalität zu zerlegen, das heißt bis zum Entwurf, nicht zur Analyse mit Anwendungsfällen.