【问题标题】:Similar Uses Case. How do the better solution?类似的用例。怎么做更好的解决方案?
【发布时间】:2021-05-20 09:46:33
【问题描述】:

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

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

搜索您所在城市的商店 -> 客户找到他所在城市的商店

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

按类别搜索店铺 -> 客户根据输入类别查找所有店铺

我正在考虑使用扩展,因为它们基本上做同样的事情,但有些步骤不同。

根据我的定义:扩展一般用例的用例集的替代或可选行为

所以我是这样想的

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

客户端必须能够进行这 4 种搜索。

第一个或第二个解决方案更好吗?为什么? 还有其他更好的解决方案吗?

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

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

在 UC 中添加场景会比其他解决方案更好吗?我知道 UC 可以有成功和失败的各种扩展。 我可以通过选择这样的解决方案来解决我的问题吗?

【问题讨论】:

  • 你不应该陷入功能分解的陷阱。考虑一下您为不同的变体获得了多少附加值。很可能你可以继续使用基本的 UC Search shop 并在里面描述变体。很难给出建议,因为这在很大程度上取决于上下文。由于您在事件流下拥有它,因此我假设它们只是同一用例的不同路径。
  • @qwerty_so 感谢您的解释。我的项目根据用户想要做的事情提供了 4 种不同的搜索可能性。我认为具有 4 个不同流事件的解决方案可能是正确的,但我无法确定这是否可能
  • UC 显示了正在考虑的系统为参与者提供的单个附加值。其定义会有所不同。但是人们经常开始功能分解,这是错误的。值得推荐的一本好书是 Bittner/Spence 关于用例。他们刚刚搞定了。附言如果您的 UC 图表类似于蜘蛛网,则表明设计损坏。
  • @qwerty_so 老实说,最初的四个用例增加了一个真正的附加值,即研究一家商店。如果我谈到“搜索商店”,那么这将是一个附加值。

标签: uml use-case visual-paradigm


【解决方案1】:

一切都取决于你想展示什么。

标准中所说的(formal/2017-12-05 §18.1.3.2 第 640 页):

当有一些额外的行为可能有条件地添加到一个或多个用例中定义的行为时,可以使用扩展。

因此,您的第二个图表不等同于您的第一个图表(假设用例未更改):

  • 在第一张图中,客户搜索商店 或 搜索您所在城市的商店 或 搜索按类别购物 或 ...

  • 在第二张图中,当客户搜索商店时,他还可以搜索您所在城市的商店 并且也可以搜索按类别购物 和 ...

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

注意在城市搜索商店和按类别搜索商店是搜索商店的专业化,按类别在城市搜索商店 在城市搜索商店和按类别搜索商店的专业化,所以:

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


出于这些关于扩展/泛化的理论考虑以及单独查看 UC,就像在任何关于 UC 的情况下一样,您必须检查您的 UC 是否有效 UC,是否每个都有足够的加值存在或者您只有 UC 搜索商店 吗?

【讨论】:

  • 感谢您的回复。因此,如果我使用第一个解决方案,那也是正确的。但我不确定他们的名字,这是我最大的疑问。它有效吗?我的项目允许客户选择四种类型中的一种。这些在语法上相似,但只是显示不同的搜索。
  • @MrBuffalo 第二种情况是“奇怪的”,因为扩展 UC 的名称不清楚,它们对我来说不是真正的搜索,否则无法完全添加,这是扩展
  • 在我看来,如果我想添加一些过滤器,如城市和类别,第二个解决方案会很有帮助。但我真的不想这样做。我想做不同的搜索,所以我认为这是更好的第一个解决方案。对吗?
  • @MrBuffalo 在这种情况下是的,第一个就是你想要的。或许也可以考虑概括一下,让“城市搜索店”专门“搜索店”等可能是实用的
  • 也许泛化会更好。 search shop 是抽象的,我可以进行 4 种不同的搜索。所以在这种情况下,我会这样:搜索商店定义主要流程,4 个备选方案定义每种情况。这是对的吗?
【解决方案2】:

除了Bruno的专家和全面的回答,我想表达另一个观点。

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

当我亲自寻找商店时,我的主要目标是找到一家商店。标准只是实现这一目标的手段。也许是我镇上的一家商店,也许是离我的 GPS 坐标最近的商店,也许我正在寻找给定的类别,或者我会在显示搜索结果时以交互方式优化我的条件。

指定过于详细的用例会使您很早就陷入可能预先定义或constrain your user-interface 的解决方案中,而没有真正考虑过为用户实现目标的最佳和最舒适的方法。 UML 创始人警告过这个缺点,并明确建议不要使用用例模型来设计用户界面。

因此,我会保持简单,只提供一个用例 Search shop,并在与每个 UC 相关联的描述中描述更具体的意图/期望(最好使用 essential use-cases)。

【讨论】:

  • 谢谢,所以如果我有 4 种类型的搜索,我不会解释所有这些,但足以解释搜索商店的“想法”?
  • @MrBuffalo 完全正确!并且您可以看到在您的手机上通过 GPS 搜索商店不在您的识别列表中。但这是移动用户期望的第一件事。如果你保持这个想法抽象,你就会对这些想法更加开放。而且您的软件设计也将保持更通用并能够应对这种演变(例如使用更通用的query pattern):-)
  • 太棒了!感谢您的帮助!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-07-20
  • 2011-11-21
  • 1970-01-01
相关资源
最近更新 更多