4

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

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

最佳做法是什么？

4

4 回答 4

4

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

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

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

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

于 2010-03-15T16:07:17.397 回答
1

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

(a) 如果您真的只是对交互进行高级摘要，那么开销非常小

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

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

于 2010-03-15T16:02:05.277 回答
0

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

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

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

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

于 2010-03-15T16:00:42.673 回答
0

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

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

  • C：存在什么形式的插入操作。您可以插入未完全填充的行吗？您可以插入没有 ID 的行吗？你能找回上次插入的 ID 吗？您可以选择性地取消插入吗？重复键或约束失败会发生什么？是否有 REPLACE INTO 等价物？

  • R：你可以选择哪些领域？可以任意分组、排序吗？您可以创建聚合字段、别名吗？您如何检索嵌入的（有很多等）数据？你如何指定递归深度，限制？

  • U, D：见 R + C

于 2010-03-15T17:54:38.263 回答