Uml 类似的用例。如何找到更好的解决方案？

对于我的项目，我需要做用例图。 这些是我的用例，但我认为这个解决方案不正确。

搜索店铺->客户在系统中查找所有店铺

搜索您所在城市的店铺->客户查找其所在城市的店铺

按城市按类别搜索店铺->客户可在输入城市中查找具有输入类别的店铺

按类别搜索店铺->客户使用输入的类别查找所有店铺

我在考虑使用一个扩展，因为它们基本上做相同的事情，但有些具有不同的步骤

根据我的定义：扩展通用用例的用例集的可选或可选行为

所以我就这样想

但我不知道我的解决方案是否正确，因为我不确定

客户端必须能够执行这4项搜索

第一种还是第二种解决方案更好？为什么？ 还有其他更好的解决方案吗

编辑：我正在尝试一个新的解决方案

我的问题：客户可以在系统中进行不同的搜索。

向矿山UC添加场景可能比其他解决方案更好？我知道UC可以有成功和失败的不同扩展。

---

我可以选择这样的解决方案来解决我的问题吗？

这取决于你想展示什么

A根据标准（§18.1.3.2第640页，共页）：

当有一些额外的行为应该被添加到一个或多个用例中定义的行为中时（可能是有条件的），可以使用Extend

因此，您的第二个图并不等同于第一个图（假设用例不变）：

• 在第一张图中，客户搜索商店或在您所在城市搜索商店或按类别搜索商店或

• 在第二张图中，当客户在此期间搜索店铺时，他也可以搜索您所在城市的店铺，也可以按类别搜索店铺和

也许您想说，在搜索过程中，可以在城市和/或类别中为搜索添加过滤器，在这种情况下，您可以使用2个扩展：

注：城市搜索商店和分类搜索商店是搜索商店的专业化，城市搜索商店是城市搜索商店和分类搜索商店的专业化，因此：

如果你非常喜欢UC中的泛化

---

---

出于对扩展/泛化的理论考虑，以及对UCs本身的观察，就像在任何UC案例中一样，您必须检查您的UCs是否有效UC，每一个都有足够的附加值存在，还是你只有UC搜索商店？

除了专家和全面的答案之外，我想表达另一个观点

虽然UML不知道用例应该或不应该表达什么，但人们普遍认为用例应该对应于参与者的目标

当我个人寻找一家商店时，我的主要目标是找到一家商店。这些标准只是实现这一目标的手段。也许是我所在城市的一家商店，也许是离我的GPS坐标最近的商店，也许我正在寻找一个给定的类别，也许我会在显示搜索结果时以交互方式改进我的条件

指定过于详细的用例将使您很早就锁定到一个解决方案中，该解决方案可能是预先定义的，或者没有真正考虑到为用户实现目标的最佳和最舒适的方式。UML创始人警告了这个缺点，并明确建议不要使用用例模型来设计用户界面

---

因此，我将保持它的简单性，只需要一个用例

搜索商店

，并在与每个UC相关的描述中描述更具体的意图/期望（最好使用）。

感谢您的回复。因此，如果我使用第一种解决方案，它也是正确的。但我不确定他们的名字，这是我最大的疑问。它有效吗？我的项目允许客户从四种类型中选择一种。它们在语法上相似，但只是显示不同的搜索。@Buffalo先生，第二种情况是“奇怪的”，因为扩展UCs的名称不清楚，他们不是真正的搜索我，否则你不能完全添加，这是扩展的作用。我认为第二个解决方案是有帮助的，如果我想添加一些过滤器，如城市和类别。。但我真的不想这么做。我想做不同的搜索，所以我认为这是最好的第一个解决方案。对吗？@Buffalo先生如果是这样的话，第一个就是你想要的。或许也可以概括一下，有可能有实用的“城市搜索专卖店”专门的“搜索商店”ETCH推广或许会更好。搜索商店是抽象的，我可以进行4种不同的搜索。所以在本例中，我会这样做：Search shop定义了主流程，4个备选方案定义了每个案例。这是对的？你不应该落入功能合成的陷阱。考虑一下不同的变体能为您带来多大的附加值。可能您可以继续使用基本的UC

搜索商店

，并描述里面的变体。很难给出建议，因为这在很大程度上取决于上下文。既然你有它在事件流中，我会假设它们只是同一用例的不同路径。@qwerty_谢谢你的解释。我的项目提供了4种不同的搜索可能性，基于用户想要做什么。我认为有4个不同流事件的解决方案可能是正确的，但我无法确定这是否可能。UC显示了正在考虑的系统为参与者提供的单个附加值。对此的定义将有所不同。但是人们经常开始功能分解，这是错误的。关于用例的Bittner/Spence是一本值得推荐的好书。他们刚刚搞定了。如果有的话