用例图包括答案

【问题标题】：Use case diagram includes用例图包括
【发布时间】：2017-10-11 16:10:01
【问题描述】：

我有一个关于用例图的问题。如图所示，用户可以输入或更新他的名字和他的问题。

如您所见，用户在第一次输入他的信息时需要输入名称和问题（因此包含）。但是，如果他希望更新他的信息，图表是否表明他必须同时修改名称和问题（因为它们包含在内）？

例如，如果他拼错了自己的名字但正确输入了他的问题，这将是一个问题。因为这意味着他必须同时更新名称和问题。

我应该有两个单独的用例，其中“输入”一个由包含组成，“更新”一个由扩展组成？

感谢您的帮助！

【问题讨论】：

用例“用户输入/更新信息”除了包含的两个案例之外还有其他内容吗？为什么无法摆脱“用户更新信息”一项？
是的，它还有大约十个其他包括。不确定我是否理解您的第二个问题。也期待您的来信。
Johny，你也可以有可选的包含。并不是因为你包含了一个用例，它就会被包含在所有场景中。您可能有不包含特定用例的场景。（并且没有，这并不意味着你应该使用extend）

【解决方案1】：

如果您实际上只使用一次，那么提取包含/扩展用例是没有意义的。继续使用Enter/update info 作为单一用例，并在 UC 流程中描述上述内容。

通常远离包含/扩展，因为在几乎所有情况下（我已经看到）人们只是将它用于功能分解。这不是 UC 的全部意义所在。他们在那里确定所考虑的系统向其参与者提供的单个附加值。

【讨论】：

感谢您抽出宝贵时间回答。在上述情况下，“名称”和“问题”不是单一的附加值吗？当然，输入这些值的参与者可以分别输入这两个值，那么它们不应该被视为参与者使用的唯一值吗？在我看来，仅仅“输入/更新信息”可能不够具体。
这取决于上下文。但是接下来：您会认为“输入名字”和“输入姓氏”是两个不同的用例吗？
好吧，我可能会将处于如此低抽象级别的具体元素放在 UC 描述中，而不是放在图表上。这是正确的选择吗？
您需要识别附加值。所以（我不知道这个领域）它可能意味着拥有 2 个 UC：Enter personal information 和 Enter problem 作为两个单独的 UC，而不是通用的。只关注附加值，而不是功能！对于总是考虑程序逻辑/功能的人来说，这是困难的部分。阅读 Bittner/Spence 以获得正确的想法。