【发布时间】: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