规范：CRUD 的用例答案

【问题标题】：Specification: Use cases for CRUD规范：CRUD 的用例
【发布时间】：2010-03-15 15:49:48
【问题描述】：

我正在编写产品需求规范。在本文档中，我必须描述用户与系统交互的方式非常高级。其中一些操作是对某些对象的“创建-读取-更新-删除”。

问题是，在为这些操作编写用例时，正确的做法是什么？我可以只编写一个名为“管理对象 x”的用例，然后将这些操作作为包含用例吗？还是我必须为每个操作、每个对象创建一个用例？我看到最后一种方法的问题是我会写很多我觉得对理解问题没有真正贡献的页面。

最佳做法是什么？

【问题讨论】：

【解决方案1】：

用例的最初概念是，它们与参与者和类定义一样，而且——坦率地说，一切——享受继承，以及<<uses>> 和<<extends>> 关系。

用例超类（“CRUD”）是有意义的。许多用例都是对“CRUD”的微不足道的扩展，其中插入了一个实体类型。

一些用例将是“CRUD”的有趣扩展，具有变体处理场景——也许——作为检索的一部分的花哨搜索，或创建或更新的多步骤过程，或删除的复杂确认.

随意使用继承来简化和规范您的用例。如果您使用 UML 工具，您会注意到用例有一个可用的“继承”箭头。

【讨论】：

【解决方案2】：

答案实际上取决于交互的复杂程度以及对象之间可能有多少变化。我建议您为每个 CRUD 开发特定用例

有两个真正的原因

(a) 如果你真的只是对交互做一个高层次的总结，那么开销是很小的

(b) 我发现指定一组通用用例来修改“资源”然后扩展/覆盖特定对象的特定步骤很有用。显然，通用的“资源”用例中捕获了常见的行为。

随着您对该领域的了解不断加深（即随着业务用户向您提出更多要求），您更有可能添加而不是删除 CRUD。

【讨论】：

【解决方案3】：

区分工作流案例和资源/对象生命周期是有意义的。它们相互作用，但它们不一样；将它们都指定是有意义的。

用例场景或更扩展的工作流程规范通常描述案例如何通过系统的工作流程进行。这通常包括与各种不同资源的交互。这些相互作用通常可以表征为 C、R、U 或 D。

资源生命周期提供了特定（类型）资源（对象）可能发生的事情的过程模型。它们通常是琐碎的“花”模型，表示：C、R、U、D 中的任何一个都可能以任何顺序发生在该资源上，因此它们本身并不是很有趣。

两者之间的联系在于工作流和生命周期中的步骤重合。

【讨论】：

【解决方案4】：

我觉得表示——只要它有意义且可读——并不重要。在所有细节上都符合 UML 规范尤其无关紧要。

重要的是，您明确说明了实现所需的操作和操作类型。

C：存在什么形式的插入操作。您可以插入未完全填充的行吗？您可以插入没有 ID 的行吗？你能找回上次插入的 ID 吗？您可以选择性地取消插入吗？重复键或约束失败会发生什么？是否有等效的 REPLACE INTO？
R：您可以选择哪些字段？可以任意分组、排序吗？您可以创建聚合字段、别名吗？您如何检索嵌入的（有很多等）数据？如何指定递归深度、限制？
U、D：见 R + C

【讨论】：

其实，在这一点上，我对技术要求并没有那么深入。用例通常更像“用户创建文档”，而不是“用户更新表 A，修改列 B 并删除 C 中的值”
什么是“用户创建文档”？我的意思是，规范中少即是多，但是如果您不知道涉及哪些操作，在“用户创建文档”中定义，那么编写“用户创建文档”有什么意义？当然你不必说一个 ID/PK 有多少位，但如果你定义了 CRUD，我想知道要准确实现的操作。
那属于用例文档吗？我认为那属于下一级设计。