如果我有一个有两个子案例的案例，我应该使用1或2个用例吗？

Question

假设我有这个例子。有一个厨师(演员)和一个用例烹饪食物。如果有两种食物可供选择(比如意大利面和比萨饼)。我应该创建一个用例: CookFood，然后在变体部分添加Pasta和Pizza，还是应该创建两个用例: CookPasta和CookPizza。

Answer 1

记住，编写用例的目的是进行交流。

如果你写了一份文件，上面写着:用例演员会做饭。这不是很有趣。如果这个用例是厨师的许多职责的一部分:管理员工，订购食物，准备健康检查，那就更有趣了。

如果烹饪比萨饼和意大利面的用例在你的工作水平上是相同的，那么将用例作为简单的烹饪食物是可以的。

但是，如果您需要更详细的用例，显示所需的设备，如烤箱和锅，那么“烹饪食物”太抽象了。

如果你所需要的东西对你来说并不明显，那么你很可能只会在有理由的情况下使用这个用例。不要在信仰上工作。在你明白为什么要这样做之前，要问清楚这需要做什么。然后你就会知道你需要什么来沟通。

Answer 2

我们有所有的元素吗?

以Ivar Jacobson的定义为例，它是用例建模发明家的原始(免费电子书第4页)：

用例是使用系统实现特定用户特定目标的所有方法。将所有用例集合放在一起，您将得到使用系统的所有有用方法，并说明它将提供的价值。

目前，您已经确定了主要的参与者(首席)和一些潜在的用例，但是您还没有告诉我们任何关于我们分析的最重要的开始:正在考虑的系统是什么？

你在找什么级别的细节?

科伯恩阐述了用例(在他的“编写有效用例”一书中)：

我们已经看到，场景中的目标和交互都可以展开成更细粒度的目标和交互。

他指出有不同的目标水平 (因此，不同级别的用例)：

• 高级目标(他称它们为云和小猫)：这些用例提供了对系统目标的非常高层次的概述(例如，经营一家餐厅，细分为管理房间和管理厨房)和广泛类别的行为者(例如工作人员、客户、供应商)。
• 用户目标(他称之为“查看级别”)：这是典型的“厨师级”。
• 子功能目标(他将靛蓝称为靛蓝，因为您现在在查看级别)：这是对用户目标的进一步分解。

你用例的目的是什么?

下一个问题是您的用例是什么：

• 您想知道在UML图上放哪一个用例吗？
• 或者您想要更详细的描述用例，以便编写规范。

不知道我们谈论的是什么系统，您的意图是什么，以及您需要的详细程度，因此，这是很难客观地评估什么是最好的选择对你。

此外，Jacobson和其他建议通过考虑价值来寻找用例。当然，这不是我们感兴趣的价值，而是用户的用例价值。

非正式讨论/意见

当然，如果从用户层面来看，我会认为“烹饪食品”是用例的主要候选对象。从ERP背景来看，我认为Pasta和Pizza只是实体/数据，以及制作它们的配方(如果您不熟悉烹饪或加工行业，那么配方的制造等价物将是BOM +一个路由)

如果需要描述"cook Pizza“和"cook Pasta”之间的过程差异，我会在Cockburn类用例(场景)中将它们作为子变体来描述。但是，没有什么能阻止你用泛化的关系来展示这三种关系。

Answer 3

JAAAY，我打赌你觉得你不能在两种选择之间做出决定，这两种选择似乎各有优缺点。这是真的，这是一个错误的两难处境。所有的用例都是完全有效的，因为它们在不同的层次上。

Write all 3 use cases, no need to choose.

我不建议省略“CookFood”和“CookPasta”有一个具体的原因。既然你真的有这样的想法，那就意味着，在你的脑海中，你已经明白，在每一个想法中，都有一些重要而独特的东西。这可能是(在这里猜测)，因为'CookFood‘用例对业务团队至关重要，而'CookPasta’是他们甚至不想听到的。但是开发团队迫切希望在获得“CookPasta”的同时，仍然拥有“CookFood”的整体形象。

看看下面的一个例子。为了说明这一想法，我跳过了大部分内容，以一种风格编写用例，其中包括它们的级别。

情景1(摘要级)：主任做好他的工作

酋长任意按任意顺序执行下列任何步骤：

1. 局长管理厨师。
2. 主更新菜单。
3. 厨师准备一顿饭。

场景2(用户目标级别)：库克准备一顿饭

1. 厨师从厨房的队列中挑选一顿饭。
2. 厨师挑选食材。
3. 库克根据所选的饭菜执行以下操作之一：
   1. 厨师准备意大利面。
   2. 厨师准备披萨。
   3. 学员准备祝酒。

4. 厨师送餐给仆人排队。

场景3(子功能级)：厨师准备意大利面

1. 厨师挑选煮好的意大利面。
2. 厨师准备调料。
3. 库克把它们混合在一起。
4. 用微波炉加热意大利面一分钟。