我正在编写产品需求规范。在本文档中，我必须描述用户可以在很高的层次上与系统交互的方式。其中一些操作是对某些对象进行“创建 - 读取 - 更新 - 删除”。
问题是，在为这些操作编写用例时，这样做的正确方法是什么？我是否只能编写一个名为“管理对象x”的用例，然后将这些操作包含在用例中？或者我必须为每个对象创建一个用例？我在最后一种方法中看到的问题是，我会编写相当多的页面，我认为这些页面并没有真正有助于理解问题。
最佳做法是什么？
答案 0 :(得分：3)
用例的最初概念是，它们与演员和类定义一样，并且 - 坦率地说 - 一切 - 享受继承，以及<<uses>>和<<extends>>关系。
用例超类（“CRUD”）是有道理的。许多用例是“CRUD”的简单扩展，实体类型插入用例。
一些用例将是“CRUD”的有趣扩展，具有变体处理方案 - 可能 - 作为Retrieve的一部分的花哨搜索，或创建或更新的多步骤过程，或者对Delete的复杂确认
随意使用继承来简化和规范您的用例。如果您使用UML工具，您会注意到用例具有可用的“继承”箭头。
答案 1 :(得分：1)
答案实际上取决于交互的复杂程度以及从一个对象到另一个对象可能有多少变化。我建议您为每个CRUD开发特定用例
有两个真正的原因（a）如果你真的只是对交互进行高级别的总结，那么开销非常小
（b）我发现指定一组通用用例来修改“资源”然后扩展/覆盖特定对象的特定步骤很有用。显然，通用行为是在通用的“资源”用例中捕获的。
随着您对域的理解的发展（即，当业务用户对您提出更多要求时），您更有可能添加到CRUD而不是删除它。
答案 2 :(得分：0)
区分工作流案例和资源/对象生命周期是有意义的。 他们相互作用，但他们不一样;指定它们都是有意义的。
用例场景或更多扩展工作流规范通常描述案例如何通过系统的工作流程。这通常包括与各种不同资源的交互。这些相互作用通常可以表征为C，R，U或D.
资源生命周期提供特定（类型）资源（对象）可能发生的事件的过程模型。它们通常是琐碎的“花”模型，它们说：C，R，U，D中的任何一个都可能以任何顺序发生在这个资源中，所以它们本身并不是很有趣。
两者之间的联系是工作流程和生命周期的步骤重合。
答案 3 :(得分：0)
我觉得有代表性 - 只要它有意义且可读 - 无所谓。在所有细节中遵守UML规范尤其无关紧要。
重要的是，您明确说明了实现所需的操作和操作类型。
C：存在什么形式的插入操作。你能插入没有完全填充的行吗？你可以插入没有ID的行吗？你能检索最后插入的ID吗？你有选择地取消插入吗？重复键或约束失败会发生什么？是否有REPLACE INTO等价物？
R：你可以选择哪个领域？你可以做任意分组，订单吗？你能创建聚合字段，别名吗？如何检索嵌入（有很多等）数据？你如何指定递归深度，限制？
U，D：见R + C