专业化或扩展点用例答案

【问题标题】：Specialization or extension point use case专业化或扩展点用例
【发布时间】：2021-10-16 13:27:42
【问题描述】：

我这里有一个删除用例。这是试图证明用户可以删除用户、项目和帖子。如果要删除用户，请从删除菜单中选择“用户”，将弹出一个用户菜单对话框，您将在其中键入名称并按“删除”以确认删除该用户。对于项目，您在删除菜单中选择“项目”，然后会弹出另一个菜单，您可以在其中键入项目名称并单击“删除”以删除项目。这就是我希望在软件中实现它的方式。但是在用例中显示它我有点困惑。这是一个很好地使用扩展点用例来演示该功能还是在这种情况下更好地使用专业化，其中父级将是“删除”，子级命名为“删除用户”，“删除项目”等......

基于 Alistair Cockburn 的编写有效用例

我个人的倾向是写“管理 X”，以获得更少混乱的优势，除非它结果由于某种原因效果不佳，通常与写作的复杂性有关，并且然后才将其分解为“创建 X”、“更新 X”、“删除 X”

专业化

【问题讨论】：

标签： uml use-case use-case-diagram

【解决方案1】：

UML 规范解释说：

扩展的 UseCase 是独立于扩展的 UseCase 定义的，并且独立于扩展的 UseCase 是有意义的。

就您而言，我怀疑Delete 的含义独立于Delete User、Delete Project 和Delete post。关键是用例独立于软件的内部实现。原则上，它们应该代表用户目标以及实现这些目标所需的一系列行为。

在编写有效的用例中，Cockburn 专门有一章介绍 CRUD 和参数化用例。他提出了一个有用的问题：

问题是，它们都是一个更大的案例的一部分，还是它们是分开的？原则上，它们是分开的，因为每个都是一个单独的目标，可能由具有不同安全级别的不同人员执行。但是，它们会使用例集变得混乱，并且可以使要跟踪的项目数量增加三倍。

他提出了几种方法，包括参数化用例的原则：通用用例（即泛化）描述一般行为，而参数用于专门化用例描述。虽然他的书是关于用例规范而不是用例图，但他描述了一个更接近于专业化而不是扩展的想法。

【讨论】：

感谢您的回复。在看到您的答案之前，我查看了编写有效的用例。我已经调整了帖子以反映我在书中提到的感受。 CRUD 操作是否可以接受改进的实现？对于我的工作，我必须解释 CRUD 操作，这就是为什么我决定使用与 CRUD 操作相关的扩展用例制作“Manage X”，以便我可以解释这一点。我觉得这个实现很有意义，尽管我很想听听你的想法。
@Krellex CRUD 确实是参数化用例的一个例子。 Cockburn 的想法是避免细节繁杂，这也是他推荐“管理 xxx”的原因。在这方面，扩展更糟糕，因为您最终会得到 5 个用例，而不是四个用例。从语义上讲，我的论点仍然成立：管理项目是一个独立的用例。如果它需要扩展，那么它就不再是独立的了。如果它不需要它们，为什么还要费心展示它们呢？此外，扩展并不是真正的扩展：实际上，它是关于专业化的。
@Krellex 如果我的推理速度太快：如果你有一个独立的“Manage X”，读者会明白这个 UC 是关于创建、更新、查看等的。）。但是，如果在同一张图上将“创建 x”显示为扩展，则意味着“创建”不是“管理”的一部分，因为需要扩展来覆盖它。这就是为什么扩展将主 UC 从其实质上清空到不再独立的原因。一个更好的例子是“管理 X”，由“克隆 X”扩展：创建目标由“管理”覆盖，但“克隆”将其扩展为可选目标。
阅读您的第一条评论后，我编辑了帖子以显示专业化版本，看看它是否更有意义。您是否会建议使用“管理项目”、“管理用户”，这意味着 CRUD，然后允许我删除扩展关系？
通常，我更喜欢有大局的 UC，并且有几个没有 CRUD 细节的“管理 Xxx”。原因是在我的领域中，通常不同的人群对不同的“Xxx”感兴趣/参与，而“Xxx”也代表不同的需求集。所以是的，如果你处于类似的情况，我会推荐这个。然后，如果需要，您始终可以在更精细的级别上进行专业化工作。成功的 UC 图表的关键是关注用户目标（CRUD 并不总是一个好方法）