生成用例
编写用例的技巧和指南。
引言
优秀应用程序的基础始于良好的设计，而良好设计的基础始于优秀的用例。在软件设计产生的所有产物中，用例最为重要。用例捕捉业务流程，并共同描述软件应用程序的功能，从用户的角度来看。
本文概述了用例及其相关挑战，提供了创建用例的技巧，并建议了一种结构化的方法来生成它们。
什么是用例？
用例是面向对象应用程序系统设计和开发中必不可少的产物。实际上，更重要的是，它们为整个应用程序的设计奠定了基础，因为应用程序类及其关系都源于用例。
最简单地说，用例就是描述软件系统需求的领域过程的结构化叙述。用例领域的专家之一 Alistair Cockburn 博士将用例描述为“系统与其外部参与者之间，围绕特定目标进行的一系列交互。” 其理念是，用户（和系统）拥有需要计算机系统帮助来实现的领域目标。目标示例包括注册学生、记录销售和确定基线。关键在于以一种对领域内的任何人来说都简单易懂的方式来表达需求。
用例的词汇必须以业务领域的术语来表达。
严格来说，用例不是面向对象的产物，可以用于任何软件开发范式。然而，它们通常与 UML 用例图相关联，该图描绘了系统的参与者、他们的职责（或目标）以及它们之间的边界之间的关联（或关系）。用例图提供了系统的参与者和用例的视觉目录、概述。
虽然 UML 用例图图形化地描绘了用例，但它们并没有定义用例。
用例的真正价值在于其文本描述，即其场景。场景是达到用例目标所需采取的一系列动作步骤，包括任何前置条件和后置条件。目标可以成功也可以失败。用例包含描述目标成功和失败的场景。成功场景是指目标已实现，而失败场景是指目标失败但仍能保护利益相关者利益。
主要成功场景是典型的或正常的成功路径。
可以将场景视为用例的执行模型（对象实例）。因此，用例场景为测试用例提供了基础。此外，场景还为系统文档和用户手册提供了基础。
用例是战略目标，由为业务领域提供价值的场景组成。
利益相关者
利益相关者是对系统行为有既得利益的某人或某“事物”。并非所有利益相关者都在系统执行时在场，但系统必须始终保护和满足利益相关者的利益。利益相关者示例包括公司股东、客户、供应商以及政府监管和报告机构。
用例描述了保护和满足利益相关者利益的行为。
参与者
参与者是任何为了实现系统目标而与系统交互的任何人或任何“事物”：个人、组织和其他计算机系统。参与者是与系统交互的利益相关者。通常，参与者有行为，并以他们在用例中所扮演的角色来表示；例如：学生、讲师、软件开发人员等。然而，参与者不是职位描述——例如：程序员 I、经理 II——除非业务领域需要。
参与者有通过用例实现的目标。
参与者通过提供输入或从中接收输出来刺激系统。主要参与者是发起或触发与系统交互以实现目标的利益相关者。主要参与者将是坐在计算机前的用户或其他计算机系统。
主要参与者是发起用例主要成功场景的人。
辅助参与者是协助主要参与者实现目标的参与者。他们与用例交互但不触发它。他们通常是外部系统或第三方组件。
一个参与者可以是一个用例的主要参与者，而对另一个用例而言是次要参与者。
用例识别
识别用例并非像最初看起来那么简单。需要考虑几个可能棘手且对成功建模业务领域至关重要的问题。按任意顺序，其中一些是：
- 寻找系统边界。
- 寻找参与者及其职责或目标。
- 确定用例的范围和级别。
- 寻找异常和失败情况。
- 链接用例（一个用例的后置条件是另一个用例的前置条件）。
此外，存在不同类型的用例，并且由不同的人以不同的方式描述。但是，大多数都从高级用例开始——称它们为系统或本质用例——然后在此基础上定义更详细的用例类型。
可以使用几种方法来识别用例：
- 识别系统中的所有参与者并定义他们的角色和职责。
- 识别并划分系统到主要功能区域。
- 识别并关联系统需要响应的所有事件。
无论使用哪种方法（或组合），该过程通常从高层级的头脑风暴会议开始，并迭代地深入细节——换句话说，是广度优先。迭代鼓励专注。每次迭代都专注于用例的一个方面。工作过快并试图捕捉太多内容很容易导致不切实际的用例，这些用例过于复杂，无法反映领域用户的实际需求。
广度优先方法
使用广度优先方法可以确保涵盖整个系统，即使只是高层次的。至少，广度优先方法可以根据需求识别系统的所有功能。
一些好处是：
- 复杂性逐渐开发并更好地理解。
- 初始用例开发迅速。
- 紧迫的日程安排可以产生所需的一切。
- 适用于所有开发方法；例如极限编程、敏捷等。
- 设计是可重用和可扩展的；后期版本将增加深度；每个级别都是一次新的迭代（或一系列迭代）。
所以，举例来说，一次典型的迭代可能如下所示：
- 迭代 1：识别利益相关者、主要参与者及其目标。
- 迭代 2：对于迭代 1 中确定的每个目标，定义主要成功场景。
- 迭代 3：对于迭代 2 中确定的每个成功场景，定义备选场景。
- 迭代 4：对于迭代 3 中确定的每个场景，定义异常条件。
在图 1 中，迭代从右侧开始向下进行。随着它们的进行，问题将浮现，这将成为形成新用例、链接现有用例以及丢弃和合并用例的动力。从这个意义上说，用例在每次迭代中都会被重构。
早期迭代中的问题是好事并且是可预期的，但是，随着迭代的继续，要警惕过于关注实现。以“执行...”或“处理...”开头的用例名称表明该用例是从实现角度编写的，而不是从领域用户的角度编写的。
用例不是函数调用。
领域图
随着用例的识别，相关的用例也会出现。在模型驱动架构方法中，相关的用例被分组到应用程序域中，从中开发域图。域是自主的实体，按其功能逻辑分组。域图将系统描绘成不同的、独立的域，它们协同工作以提供应用程序的功能。
在图 2 中，书店的相关用例被分组在一起，一目了然地显示了应用程序中的主要域。每个域都包含实现域功能的子系统。
领域图鼓励并行设计和开发。
验证
验证决定了用例的可信度，并且对于捕捉业务流程至关重要。随着用例的重构，提出以下问题：
- 用例是否捕捉了业务流程？
- 是否需要添加任何细节？
- 参与者的目标是否会实现？
- 用例是否可以简化？
- 是否存在未解决的附加目标？
- 是否存在未表示（直接或间接）的附加参与者？
用例格式
存在许多用例格式，有些比其他格式提供更多内容。不存在适用于所有项目的单一用例格式。有些项目遵循轻量级开发方法，需要较少的文档，可能是因为时间安排紧凑；其他项目是重量级的，需要更多的文档，可能是为了任务关键型项目。
在《编写有效的用例》一书中，Cockburn 博士描述了以下格式：
- 全详尽：最详细。此模板描述了参与者、利益相关者、利益相关者权益保护、性能问题、前置条件和后置条件、异常、注释和附注。在需要正式且完整的文档时使用。
- 随意：以段落风格编写，最多几段。不如全详尽格式正式，内容也较少。
- 简要：一段总结业务流程。仅提及主要成功场景和失败场景中的重要步骤。
此外，还可以考虑另外两种格式：
- 常规：这将是常规方法，它比随意格式更详细地指定和定义设计模型，但仍少于全详尽格式。设计评审将比敏捷方法（下文）更严格、容忍度更低，并且会应用更多的精确性和严谨性。
- 敏捷：使用此格式的项目将实践敏捷建模和开发方法来非常快速地生成软件，但仍包含可接受的设计。UML 产物虽然完整，但细节会比常规开发方法少，并且更侧重于更高级别的视角。小型项目或有严格截止日期的项目可能属于这种情况。
选择最适合项目的格式。
建模创建、读取、更新、删除 (CRUD)
理想情况下，CRUD 功能应以业务流程的形式表达——用户执行的操作。用例中的语义非常重要，应使用用户的语言来表达——而不是开发人员的语言、系统的功能或数据库建模术语。良好的设计是从用户角度看待系统。
CRUD 用例的问题在于它们描述了技术实现，而没有解释这对用户有何价值。充其量，它是一个在用例场景的上下文中实现的一个低级目标。
考虑文字处理器的用例。哪一个更能说明业务案例：创建样式、更新样式、导入样式、删除样式，还是在文档中确保格式一致性？后者最能表达用户的目标。虽然创建样式、更新样式、导入样式和删除样式反映了在业务领域内发生的功能，但它们并没有表达用户格式化文档的目标。相反，目标已被分解为离散的功能。
抵制将用例分解为功能的倾向。
或者，再考虑一个例子。出于安全目的，用户登录应用程序是很常见的。然而，登录不是用户的业务目标。换句话说，例如库存系统的用户不会对自己说：“今天，我的目标是以最高效的方式登录和退出库存系统。” 此外，用户不会因为登录系统的效率而受到评估。她也不会因为一天登录 45 次而获得加薪。
不要将 CRUD 和辅助功能（如登录）包含在业务用例中，而是将它们分离到系统用例中，这些系统用例单独存在于比业务用例更低的详细级别。
用技术术语陈述系统过程。
开发人员倾向于从实现的角度思考。然而，这种倾向需要被抵制，并持续地加以防范，以避免在编写业务用例时出现。此外，开发人员不应强迫用户采用实现语言。是开发人员需要采用用户的语言，而不是反过来。
用用户的角度陈述业务流程。
生成用例
以下步骤提出了一个用于生成用例的结构化大纲。它们旨在在小组会议中进行，并由开发团队成员——以及可能的客户代表——参加。设计会议气氛开放而轻松，鼓励讨论，即使是激烈的讨论。理想情况下，会议主持人应在总结和阐明小组提出的想法并将其转化为连贯陈述方面经验丰富。
所需材料：记号笔、白板（用于头脑风暴）、翻页纸
注意：这些步骤假设需求已收集完毕。
- 从需求中生成初始的参与者-目标列表。
参与者-目标列表在最高级别描述了应用程序的行为。尽管如此，每个主要参与者都已被识别并与其目标相关联。这些目标最终将形成用例。
- 识别利益相关者及其利益。
- 根据利益相关者，识别并列出主要参与者。如有必要，从简短的叙述开始以识别初始参与者和目标。
- 对于每个参与者，识别目标，必要时进行重构。
- 验证参与者-目标列表并生成项目叙述。
- 在小组讨论中，缓慢地逐步进行叙述，将关键步骤以书面形式记录在白板上。
- 参考叙述，确保参与者-目标列表捕捉了叙述。所有参与者及其目标都应在叙述中显而易见。如果不是，则根据需要重构参与者-目标列表。
- 完成后，每位团队成员都应理解并能够重复该叙述。
此步骤将产生两个产物：
- 一个经过验证的参与者-目标列表，该列表捕捉了系统的行为并保护了利益相关者的利益。
- 一个详细的项目叙述，其中识别了所有项目利益相关者及其利益。该叙述是极好的项目文档，有助于确保用例能够保护利益相关者的利益。它还确保所有开发人员对项目有共同的理解，因为所有开发人员都参与了叙述。
注意：如果叙述已在步骤 2 之前生成，请与整个小组一起重新审视它。无疑，随着问题的出现和批评的到来，它将发生变化和改进。
- 迭代地生成初始用例摘要。
在第一次迭代中，重点关注主要参与者及其主要成功场景。在后续迭代中，添加达到所需用例格式所需的详细信息。
- 从经过验证的参与者-目标列表中选择对核心架构有显著影响的参与者-目标。
- 用业务流程的术语表达目标；解决用户的需求，而不是其实现。
- 避免使用 CRUD 术语。用例必须以业务词汇表达——它应该对业务用户有意义。例如，与其说“创建学生”，不如说“将学生注册到课程”可能更合适。CRUD 用例更适合作为“系统”用例，而不是“用户”用例。
- 避免按功能确定用例。
- 生成领域图
- 将用例划分为相关的、自主的域。
- 考虑每个域都可以独立设计甚至实现。
结论
用例是设计并最终交付用户期望的优质软件的第一步。由于用例从用户角度捕捉业务需求，因此没有其他设计活动能获得更高的投资回报。类似于房屋的规范，用例提供了应用程序的规范。从这些规范中，生成用于构建系统的设计产物。最终，应用程序的设计、构建和用户的接受都依赖于扎实的用例。不要忽视软件应用程序生命周期中的这一基本步骤。
附加链接
- Scott Ambler 提供了关于绘制用例图的精彩技巧。
- Alistair Cockburn 的《用目标构建用例》。
- Craig Larman 的《用例模型：在上下文中编写需求》。
- 用例十大错误.