用例图:何时分解用例,何时不分解?

Use-case diagram: When to decompose use-case and when not to?

提问人:Toàn Trần 提问时间:8/9/2023 最后编辑:Toàn Trần 更新时间:8/10/2023 访问量:70

问:

举个例子,比如说,我想为人造自动售货机画一个用例图,如下所示:

  • 自动售货机有 3 个选项:、 和 。carbonated drinksteapure water

  • 用户只能选择以下一项订单:

    • 如果用户选择,用户需要选择哪个品牌:比如可口可乐或百事可乐。carbonated drinks
    • 否则,如果用户选择,那么他/她必须选择糖的量。tea
    • 否则,如果用户选择,则仅此而已。pure water
  • 选择饮料后,用户必须选择饮料的数量(有点做作)。然后,机器会发送一条确认消息供用户确认。

我试过这个,但不太确定,不知道要保留什么,添加什么或删除什么。

问题是:

  • 2 和 here 应该作为用例独立保存,还是应该将它们与大用例合并:?Choose the number of drinksConfirmBuy a kind of drink

  • 如果要保留其中至少 1 个,我应该将它们绘制为包含用例还是应该将它们绘制为独立的用例?Buy a kind of drink

  • 这 3 个用例 , , 我将其视为 的离散化。对于 和 ,我是否应该保留包含的用例:或者我是否也应该删除它们?Buy carbonatedBuy teaBuy pure waterBuy a kind of drinkBuy carbonatedBuy teaChoose brandChoose sugar amount

  • 更一般的问题:什么时候应该将执行一些大型用例的步骤保留为用例,什么时候不应该?这里有很多相同的问题,但答案并不一致。

UML 用例

评论

0赞 qwerty_so 8/10/2023
这不是UC图,而是功能分解。

答:

1赞 qwerty_so 8/10/2023 #1

用例是关于什么而不是如何。后者进入 Activity 并拆分为 Actions。用例仅显示正在考虑的系统为其参与者带来的附加值。

所以唯一的附加值是,仅此而已。Sell drink

我建议阅读 Bittner/Spence 关于用例的信息。他们称之为综合,这是正确的词。不是分析,更不是分解。

奇怪的是,技术人员总是想分解东西。好吧,我知道这很难学习,因为我也一直在挠头。它可能如此复杂,因为它是关于简单的。

评论

0赞 Toàn Trần 8/10/2023
谢谢你的回答。只是另一个问题。为什么分裂成 , ...也算作功能分解?我明白为什么我的被算作这样,但在这里他们也这样分裂。是因为他们的拆分与 不同,还是他们也在分析用例?谢谢。Sell drinkSell carbonated<<include>>sell drink
0赞 qwerty_so 8/10/2023
任何泡沫都必须是单一的附加值。我看不出用水卖啤酒有什么区别,因为两者都可以解渴。如果你能解释其中的区别(可能考虑到酒精),那就继续吧。基本上:找到附加值;不要解释它是如何实现的!
0赞 Toàn Trần 8/10/2023
明白了。谢谢!