规范：CRUD 用例
我正在编写产品需求规范。在本文档中，我必须描述用户在非常高的级别上与系统交互的方式。其中一些操作是对某些对象的“创建-读取-更新-删除”。
问题是，在为这些操作编写用例时，正确的方法是什么？我可以只编写一个名为“管理对象 x”的用例，然后将这些操作包含在用例中吗？或者我是否必须为每个操作、每个对象创建一个用例？我看到最后一种方法的问题是，我会写很多页，我觉得这些页并没有真正有助于理解问题。
最佳实践是什么？
I am writing a Product requirements specification. In this document I must describe the ways that the user can interact with the system in a very high level. Several of these operations are "Create-Read-Update-Delete" on some objects.
The question is, when writing use cases for these operations, what is the right way to do so? Can I write only one Use Case called "Manage Object x" and then have these operations as included Use Cases? Or do I have to create one use case per operation, per object? The problem I see with the last approach is that I would be writing quite a few pages that I feel do not really contribute to the understanding of the problem.
What is the best practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
用例的最初概念是，它们就像参与者和类定义一样，并且——坦率地说，一切——都享受继承，以及
<> 和< ;<扩展>>关系。用例超类（“CRUD”）是有意义的。许多用例都是“CRUD”的简单扩展，并将实体类型插入到用例中。
一些用例将是“CRUD”的有趣扩展，具有变体处理场景，例如作为检索的一部分的奇特搜索，或者创建或更新的多步骤过程，或者删除的复杂确认。
请随意使用继承来简化和规范您的用例。如果您使用 UML 工具，您会注意到用例有一个可用的“继承”箭头。
The original concept for use cases was that they, like actors, and class definitions, and -- frankly everything -- enjoy inheritance, as well as
<<uses>>and<<extends>>relationships.A Use Case superclass ("CRUD") makes sense. A lot of use cases are trivial extensions to "CRUD" with an entity type plugged into the use case.
A few use cases will be interesting extensions to "CRUD" with variant processing scenarios for -- maybe -- a fancy search as part of Retrieve, or a multi-step process for Create or Update, or a complex confirmation for Delete.
Feel free to use inheritance to simplify and normalize your use cases. If you use a UML tool, you'll notice that Use Cases have an "inheritance" arrow available to them.
答案实际上取决于交互的复杂程度以及对象之间可能有多少种变化。我建议您为每个 CRUD 开发特定用例有两个真正的原因
(a) 如果您确实只是对交互进行高级摘要，那么开销非常小
(b)我发现指定一组通用用例来修改“资源”然后扩展/覆盖特定对象的特定步骤很有用。显然，常见行为是在通用“资源”用例中捕获的。
随着您对领域的理解不断加深（即，随着业务用户向您提出更多要求），您更有可能添加而不是删除 CRUD。
The answer really depends on how complex the interactions are and how many variations are possible from object to object. There are two real reasons why I suggest that you develop specific use cases for each CRUD
(a) If you really are only doing a high-level summary of the interaction then the overhead is very small
(b) I've found it useful to specify a set of generic Use Cases for modifying 'Resources' and then extending / overriding particular steps for particular objects. Obviously the common behaviour is captured in the generic 'Resource' use cases.
As your understanding of the domain develops (i.e. as business users dump more requirements on you), you are more likely to add to the CRUD rather than remove it.
区分工作流案例和资源/对象生命周期是有意义的。
它们相互作用，但并不相同；指定它们两者是有意义的。
用例场景或更扩展的工作流程规范通常描述案例如何通过系统的工作流程进行。这通常包括与各种不同资源的交互。这些交互通常可以表征为 C、R、U 或 D。
资源生命周期提供了特定（类型）资源（对象）可能发生的情况的过程模型。它们通常是琐碎的“花”模型，表示：C、R、U、D 中的任何一个都可能以任何顺序发生在该资源上，因此它们本身并不是很有趣。
两者之间的联系在于工作流程和生命周期中的步骤是一致的。
It makes sense to distinguish between workflow cases and resource/object lifecycles.
They interact but they are not the same; it makes sense to specify them both.
Use case scenarios or more extended workflow specifications typically describe how a case may proceed through the system's workflow. This will typically include interaction with various different resources. These interactions can often be characterized as C,R,U or D.
Resource lifecycles provide the process model of what may happen to a particular (type of) resource (object). They are often trivial "flower" models that say: any of C,R,U,D may happen to this resource in any order, so they are not very interesting by themselves.
The link between the two is that steps from the workflow and from the lifecycles coincide.
我觉得表达——只要它有意义并且可读——并不重要。在所有细节上遵守 UML 规范尤其无关紧要。
重要的是，您的规范清楚地说明了实现所需的操作和操作类型。
C：存在什么形式的插入操作。您可以插入未完全填充的行吗？可以插入没有 ID 的行吗？能找回上次插入的ID吗？可以有选择地取消插入吗？重复键或约束失败会发生什么？是否有等效的 REPLACE INTO？
R：您可以通过哪些字段进行选择？可以任意分组、排序吗？您可以创建聚合字段、别名吗？如何检索嵌入的（有很多等）数据？如何指定递归深度、限制？
U、D：参见 R + C
I feel representation - as long as it makes sense and is readable - does not matter. Conforming to the UML spec in all details is especially irrelevant.
What does matter, that you spec clearly states the operations and operation types the implementaton requires.
C: What form of insert operations exists. Can you insert rows not fully populated? Can you insert rows without an ID? Can you retrieve the ID last inserted? Can you cancel an insert selectively? What happens on duplicate keys or constraints failure? Is there a REPLACE INTO equivalent?
R: By what fields can you select? Can you do arbitrary grouping, orders? Can you create aggregate fields, aliases? How can you retrieve embedded (has many etc.) data? How do you specify depth of recursion, limits?
U, D: see R + C