当用例有扩展点或包含某些内容时，用例场景应该是什么样的？

Question

我有一个简单的UC图。

首先，当客户输入修理订单时，系统检查订单是否可以处理(如果修理公司可以修复这种设备)- UC“输入修复订单”。只有当公司能够修复此设备时，客户才会启动另一个UC“选择修复类型”，最后，取决于客户选择哪种修复类型，它将转到“输入家庭地址”或“进入城市”。

我的问题是，如果我想为UC构建用例场景，“输入修复顺序”应该是什么样的呢？我应该在主修课上写，客户可以输入另一个用例吗？

即：

主菜

1. 客户登录网页。
2. 客户填写订单。
3. 系统显示公司可以修复此设备的信息。
4. 客户进入UC“选择修理类型”。
5. 系统显示已保存订单的信息。

替代课程

1. 系统显示公司无法修复此设备的信息。
2. 系统显示订单尚未保存并结束用例的信息。

或者说这应该是：

主菜

1. 客户登录网页。
2. 客户填写订单。
3. 系统显示公司可以修复此设备的信息。
4. 客户进入UC“选择修复类型”并结束用例。

替代课程

1. 系统显示公司无法修复此设备的信息。
2. 系统显示订单尚未保存并结束用例的信息。

这种情况有意义吗？

Answer 1

我要做的第一件事就是扔掉用例图。在其他答案中，我经常引用Martin的话，无论是来自他的网站还是他的书，UML，他都表示在UML用例图中缺乏有用性和价值。我只想看一下用例的两个文本表示。

下一步是明确定义用例是什么。用例是用户如何与软件(或系统)交互以获得有用结果的定义，考虑到输入和对这些输入(或输出)的响应。基于这个定义，用例的文本表示的第一个例子更好，因为主课程实际上以一些有价值的事情结束。

不过，我不喜欢提取子用例，至少基于这个示例。促进详细文本描述的重用可能是有意义的，但除非与“选择修复类型”、“输入家庭地址”和“输入城市”相关的相同步骤在几个用例中被重用，否则我将在“输入修复顺序”用例中考虑这些步骤。我还想问为什么“输入家庭地址”和“输入城市”是分开的用例，因为城市是地址的一部分。这里似乎有更详细的设计决策，涉及域是如何建模的，这在用例级别上是不合适的。