假设你必须为这个简单的问题做一个用例图（这是我正在做的一个更大的练习的一部分）：
（Web 应用程序的）注册用户可以通过两种方式搜索旅游景点：按类别（例如：博物馆、公园、剧院、考古遗址）或按位置（城市、县）。
我应该如何为这个 UCD 建模？
最简单的方法是：参与者（注册用户）、两个用例（按类别搜索旅游景点和按位置搜索）、次要参与者（Web 应用程序的服务器，它将处理查询并发送回结果）。
我担心的是，这样四个类别和两种类型的位置不会出现在用例中。
我正在考虑使用“扩展”关系。例如，我将添加一个名为“Search parks”的用例，扩展用例“Search by category”。扩展点将是用户选择搜索公园的事件。
或者我可以使用“按类别搜索”和“搜索公园”之间的继承关系......嗯......我有点困惑......
你将如何使用美元来模拟这个小问题？
谢谢你，卢卡
首先，您必须意识到，用例图不能替代实际（书面）用例。用例描述包含许多重要的细节，在用例图中省略了。用例图有助于描述参与者的层次结构、相关用例和用例之间的关系，但仅此而已。
另一件重要的事情是了解实际用例是什么。考虑它们的好方法是找到演员的目标，他/她想在系统的帮助下实现。实现这个目标应该给参与者一些商业价值。我的观点是，根据您的描述，注册用户可能想要搜索观光和/或购买门票。所以这是他的目标，这应该是一个用例，不要将用例与不同的搜索方式等功能/特性混淆。
在您的第一个建议中，您有两个用例，它们仅在数据上有所不同（例如，它可能只是表单中组合框的不同选择）。如果这些差异不影响系统和参与者交互的方式，它们将与您在用例中引用的数据词汇表中的用例分开描述。这样可以避免用例描述中的许多不必要的细节。另一方面，如果描述中的步骤发生了变化（例如，当注册用户选择位置系统时，他/她可以选择另一个注册用户作为朋友，并预先选择两者最喜欢的位置或类似的东西......） ，您可以通过使用替代/扩展来捕获它。
您提到您正在开发的系统是次要参与者。不要忘记，正在开发的系统是一个隐含的参与者，并没有作为单独的参与者显示图表。使用边界框（包含不包括参与者的用例的矩形）来描述系统的范围。
终于到你的关心了。这些都只是有关数据的详细信息，而不是用例的一部分。您可以使用上面提到的数据词汇表在文本中捕获这些详细信息（通过命名所有类别等）。如果您认为数据之间的结构和关系很重要并且需要使用图表来捕获，您可以使用类图来创建数据/领域模型。
关于用例关系的最后一点 - 如果你不需要，不要使用它们。它们通常难以理解且定义模糊。永远不要使用它们来分解功能，这取决于设计，而不是用用例分析。
我讨厌在用例中描述搜索。变量太多了。这就像尝试编写一个使用浏览器的用例。
搜索是补充业务规则的早期原型设计的理想选择。