简介 用例是文本形式的情节描述，广泛应用于需求的发现和记录工作中。用例会影响项目的众多方面（包括OOA/D），用例也将作为本书案例研究中许多后继制品的输入。图6-1描述了UP制品的影响力，其中特别强调了文本形式的用例。将高阶目标和用例图作为输入，来创建用例文本。反之，用例也能够影响其分析、设计、实现、项目管理和测试制品。
示例 图6-1中的用例不是图形，而是文本。用例初学者的常见错误就是注重于次要的UML用例图，而非重要的用例文本。
用例通常比上述例子更为详细或结构化更强，但其本质仍然是通过编写使用系统实现用户目标的情节来来发现和记录功能性需求，也就是使用的案例。用例不是什么复杂的概念，尽管发现需求，并适当地编写通常有一定的困难。
定义：参与者、场景和用例 参与者（actor）是某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织。
场景（scenario）是参与者和系统之间的一系列特定的活动和交互，也称为用例实例（use case instance）。场景是使用系统的一个特定的情节或用例的一条执行路径。
通俗地讲，用例(use case)就是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。
用例和用例模型 UP在需求科目中定义了用例模型（Use-Case Model）。首先，这是所有书面用例的集合；同时，它是系统功能性和环境的模型。 用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。
用例模型在UP中不是唯一的需求制品。其他制品还有补充性规格说明、词汇表、设想和业务规则。这些制品都有助于需求分析，但并不是最主要的。
用例模型还可以包含UML用例图，以显示用例和参与者的名称及其关系。UML用例图可以为系统及其环境提供良好的语境图（context diagram），也为按名称列出用例提供了快捷方式。
用例不是面向对象的，编写用例时也不会进行OO分析。但这并不妨碍其有效性，用例可以被广泛应用。也就是说，用例是经典OOA/D的关键需求输入。
动机：为什么使用用例 虽然这种方法看起来像随意的注释，但是极为重要。研究人员设计了他们自己能够理解的复杂分析方法，但是会使一般的业务人员迷惑不解。而在软件项目中，缺少用户参与是项目的主要原因之一，所以任何有利于用户参与的方法是绝对值得的。
用例的另一个价值是强调了用户的目标和观点。 我们会提出这样的问题：“谁使用系统？他们使用的典型场景是什么？他们的目的是什么？”与查询系统特性清单相比，以上问题更强调以客户为中心。
富有创造力的人经常会将简单的思想变得晦涩并且过于复杂。我们经常会发现，用例建模新手过于关心那些次要的问题，比如用例图、用例关系、用例包等，而不是致力于简单地编写文本情节的实际工作中。
用例的优越性就在于，能够根据需要对复杂程度和形式化程度进行增减调节。
定义：用例是功能性需求吗 用例就是需求，主要是说明系统如何工作的功能性或行为性需求。按照“FURPS+”需求类型，用例强调了“F”（功能性或行为性），但也可以用于其它类型，特别是与用例紧密相关的那些类型。在统一过程和其他现代方法中，用例被推荐作为发现和定义需求的核心机制。
记住，用例是真正的需求（尽管不是所有的需求）。 用例的主要思想（通常）是：为功能性需求编写用例，从而降低详细的老式特性列表的重要性或减少这种列表的使用。
定义：参与者的三种类型 参与者（actor）是任何具有行为的事物，在所讨论系统（System under Discussion ,SuD）调用其他系统的服务时，还包括其自身。主要参与者和协助参与者会出现在用例文本的活动步骤中。参与者不仅是人所扮演的角色，也可以是组织、软件和计算机。相对于SuD，有三种外部参与者：
》主要参与者（primary actor）：具有用户目标，并通过使用SuD的服务完成。例如，收银员
》协助参与者（supporting actor）：为SuD提供服务（例如，信息服务）。自动付费授权服务即是一例。协助参与者通常是计算机系统，但也可以是组织或人。
》幕后参与者（offstage actor）：在用例行为中具有影响或利益，但不是主要或协助参与者。例如，政府税收机构。
- 为何要确定幕后参与者？这是为了确保确定并满足所有必要的重要事物。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。
表示法： 用例的三种常用形式 用例能够以不同形式化程度或格式进行编写：
》摘要--简洁的一段式摘要，通常用于主成功场景，前例中的处理销售就是摘要形式的用例。
- 何时使用？ 在早期需求分析过程中，为快速了解主题和范围。可能只需要几分钟进行编写。
》非正式--非正式的段落格式。用几个段落覆盖不同场景。前例中处理退货就是非正式形式的用例。
》详述--详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。
- 何时使用？确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量（例如10%）的具有重要架构意义和高价值的用例。
示例：详述风格的处理销售 详述用例（fully dressed use case）是结构化的，它展示了更多细节，并且更为深入。（P50~P55） 在迭代和进化式UP需求分析中，第一次需求讨论会应该以这种形式编写10%的关键用例。随后，对这10%中最具有重要架构意义的用例或场景进行设计和编程。
对于详细的用例有各种格式的模板。自20世纪90年代早期以来，使用最为广泛的格式是alistair.cockburn.us上提供的模板，该模板由Alistair Cockburn创建，他是用例建模方法和畅销书的作者，PPT3阐述了这种风格。
各小节的含义
绪言元素
》范围 范围界定了所要设计的系统。通常，用例描述的是对一个软件系统（或硬件加软件）的使用，这种情况下称之为系统用例（system use case） 。在更广义的范围上，用例也能够描述顾客和有关人员如何使用业务。这种企业级的过程描述被称为业务用例（business use case），这也是广泛使用用例的极好示例，但这并不是本书所要介绍的内容。
》级别 在Cockburn的系统中，用例主要分为用户目标级别或子功能级别。 用户目标级别（user-goal level）是通常所使用的级别，描述了实现主要参与者目标的场景，该级别大致相当于业务流程工程中的基本业务流程（Elementary Business Process，EBP）。子功能级别（subfunction-level）用例描述支持用户目标所需的子步骤，当若干常规用例共享重复的子步骤时，则将其分离出来，创建为子功能级别用例（以避免重复公共的文本）;信用卡支付就是子功能用例的例子，该用例可以被许多常规用例所共享。
》主要参与者 调用系统服务来完成目标的主要参与者
》涉众及其关注点列表--重要！ 该列表比看上去要重要和实用的多。它建议并界定了系统必须要做的工作。见以下引用： “[系统]实现了涉众之间的契约，同时用例详细描述了该契约的行为部分.......用例作为行为的契约，专门和完整地捕获与满足涉众关注点相关的行为” 这就回答了以下问题：用例应该包含什么？ 答案是：用例应该包含满足所有涉众关注点的事物
》前置条件和成功保证（后置条件） 前置条件（precondition）给出在用例中场景开始之前必须永远为真的条件。要注意的是，有些条件也必须为真，但是不值得编写出来。前置条件传达的是编写者认为应该引起读者警惕的那些值得注意的假设。成功保证（或后置条件）给出用例成功结束后为真的事物，包括主成功场景及其替代路径。该保证应该满足 所有涉众的需求。
》主成功场景和步骤（或基本流程） 也被称为“理想路径”场景，或更朴实的“基本流程”及“典型流程”。它描述了满足涉众关注点的典型成功路径。要注意的是，它通常不包括任何条件或分支。虽然包含条件或分支并不是错误，但是，保持一定的连贯性，并且将所有条件处理都推延至扩展部分，这种具有争议的做法更易于理解和扩展。
场景记录以下三种步骤：
1、参与者之间的交互
2、确认过程（通常由系统来完成）
3、系统完成的状态变更
》扩展（或替代流程） 扩展是重要的，并且通常占据了文本的大部分篇幅。扩展部分描述了其他所有场景或分支，包括成功和失败路径。 在整个用例编写当中，理想路径与扩展场景相结合应该满足“几乎”所有涉众所关注的问题。
扩展场景是主成功场景的分支，因此能够以对应的步骤1...N对其进行标识。
在扩展处理结束时，默认情况下，扩展场景将重新并入主成功场景，除非扩展指出了其他方式（例如，系统中断） 。 有时候，某个扩展点将非常复杂，例如“信用卡支付”扩展。在这种情况下可以使用单独的用例来表达该扩展。
如果想要描述在任何步骤（至少大多数步骤）都可能发生的扩展条件，那么可以使用“*a”、“*b”这样的标记。
有时，用例会产生分支以执行其他用例场景。在Cockburn表示法中，使用下划线表示所执行的第二个用例。假设通常使用超链接工具编写用例，那么点击具有下划线的用例名称将会显示对应的文本。
》特殊需求 如果有用例相关的非功能性需求、质量属性或约束，那么应该将其写入用例。其中包含需要考虑的和必须包含的质量属性（如性能、可靠性和可用性）和设计约束（通常对于I/O设备）
》技术和数据变元表 需求分析中通常会发现一些技术变元，这些变元是关于必须如何实现系统的，而非实现系统哪些功能，这种变元需要记录在用例中。常见的例子是，涉众制定了关于输入或输出技术的约束。
表示法：有其他格式吗？两栏变体 有时提倡使用两栏或对话的格式，这种格式强调参与者和系统之间的交互。P60
准则：以无用户界面约束的本质风格编写用例 以本质风格编写用例；摒除用户界面并且关注参与者的意图。 这种对根源目标的发现过程能够拓展视野，以促成新的和改进的解决方案。
准则：编写简洁的用例 删除“噪音”词汇，因为即使一些细微之处也会累积为繁琐，例如编写时应用“系统认证......”，而不是“这个系统认证......”
准则：编写黑盒用例 黑盒用例（black-box use case）是最常用和推荐使用的类型；它不对系统内部工作、构件或设计进行描述。反之，它以通过职责来描述系统，这是面向对象思想中普遍统一的隐喻主题--软件元素具有职责，并且与其他具有职责的元素进行协作。
通过使用黑盒用例定义系统职责，人们可以规定系统必须做什么（行为和功能需求），而不必决定系统如何去做（设计）。实际上，“分析”与“设计”的区别就在于“什么”和“如何”的差异。这是在优秀软件开发中的重要主题：在需求分析中应该避免进行“如何”的决策，而是规定系统的外部行为，就像黑盒一样。此后，在设计过程中创建满足该规格说明的解决方案。
准则：采用参与者和参与者目标的视点 以下是RUP的用例定义，源于用例创立者Ivar Jacobson：【一组用例实例，每个实例是系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察结果】 短语“对特定参与者具有价值的可观察结果”是细微而又重要的概念，Jacobson认为这是关键，因为它强调了需求分析的两个态度：
》关注系统的用户或参与者来编写需求，询问其目标和典型情况
》关注理解参与者所考虑的有价值的结果
准则：如何发现用例 为满足主要参与者的目标而定义用例。因此，基本的过程如下：
1》选择系统边界 系统仅仅是软件应用，还是将硬件和应用作为整体？是一个人使用，还是整个组织在使用？
2》确定主要参与者--通过使用系统的服务实现其目标的那些人或事物
3》确定每个主要参与者目标
4》定义满足用户目标的用例，根据其目标对用例命名。通常，用户目标级的用例和用户目标是一一对应的，但这里至少有一个例外，后面将对此进行讨论。
详细步骤1-4见P63~P65
准则：什么样的测试有助于发现有用的用例 一般来说不要提出“什么是有效用例”这样的问题，更为实际的问题是“对应用需求分析来说，表示用例的有效级别是什么？”下面给出一些经验方法：
老板测试 EBP测试 规模测试
EBP测试 EBP即基本业务过程（Elementary Business Process），是源于业务过程领域的术语，定义如下：【一个人于某一时刻在一个地点所执行的任务，用以响应业务事件。该任务能够增加可量化的业务价值，并且以持久状态留下数据，例如，批准信用卡的信用额或者确定订购的价格】ERP测试与老板测试类似，尤其是对业务价值可量化这一限制而言。用例是在会话过程中完成的任务。用例可能只需几分钟或一个小时就能完成。正如UP的定义，用例增强可观察或可量化的业务价值，由此形成了这样的解释：系统和数据具有稳定和持久状态。
规模测试 用例很少由单独的活动或步骤组成，相反，用例通常包含多个步骤，在详述形式的用例通常需要3~10页文本。用例建模中的一个常见错误就是仅将一系列相关步骤中的一个步骤定义为用例。
测试的合理违例 尽管应用中主要用例的定义和分析可以满足上述测试，但是常常会出现例外。有时，需要为子任务或常规EBP级别用例中的步骤编写单独的子功能级别用例。例如，诸如“信用卡支付”等子任务或扩展可能在多个基本用例中出现。如果有这种现象，即使不能真正满足EBP和规模测试，也需要考虑将其分离为单独的用例，并且将其连接到各个基本用例上，以避免文字上的重复。
认证用户这一用例可能无法通过老板测试，但是其步骤极为复杂，需要引起重视进行细致的分析，例如需要考虑“单点登录”特性。
应用UML：用例图 UML提供了用例图表示法，用以描述用例名称和参与者及其之间的关系（图6-3）。 【用例图和用例关系在编写用例工作中是次要的。用例是文本文档。编写用例意味着编写文本】Flower和Cockburn等世界级的用例专家都对用例图和用例关系不予重视，而是注重编写文本。借鉴大师经验的同时，简单的用例图还是能够为系统提供简洁可视的语境图，能够阐述外部参与者及其对系统的使用。【准则：绘制简单的用例图，并与参与者-目标列表关联。】
用例图是一种优秀的系统语境图(context diagram)；也就是说，用例图能够展示系统边界、位于边界之外的事物以及系统如何被使用。用例图可以作为沟通工具，用以概括系统及其参与者的行为。
准则：制图 图6-4为制图提供了建议。为了明确起见，某些人建议使用其他表示法莱突出外部计算机系统参与者，图6-5所示。
准则：不要倚重于制图，保持其简短 再次重申，用例工作之重在于编写文本，而非图形或用例关系。
应用UML：活动图 UML包含一种有助于工作流和业务过程可视化的图：活动图。因为用例涵盖过程和工作流分析，所以活动图能够成为编写用例文本的有用的辅助措施，对于那些描述复杂工作流的业务用例来说更是如此，因为其中涉及大量参与者和并发活动。
动机：用例还有其他益处么？语境中的需求 用例的动机在于关注谁是关键参与者，其目标和一般的任务是什么。除此之外，就其本质而言，用例是一种简单的、被广泛理解的形式（情节或场景形式）
正如Uses Case:Requirements in Context的书名所暗示的那样，在使用系统的典型场所的语境下，用例组织了一组需求。这是件好事，以面向用户的场景（例如用例）作为公共线索，考虑并组织需求，可以增强对需求的理解，并且能够提高需求分组的内聚性。
无论用例多么重要，但它并不是唯一必要的需求制品。最好将非功能性需求、报表布局、领域规则和其他不知所置的元素写入UP的补充性规格说明中去。
示例： Monopoly游戏 见P70
过程：在迭代方法中如何使用用例 用例是UP和其他众多迭代方法的核心。UP提倡用例驱动开发（use-case driven development）这意味着：
》功能需求首先记录在用例（用例模型）中；无论如何使用，其他需求技术（例如功能列表）都是上次要的
》用例是迭代计划的重要部分。迭代的工作是通过选择一些用例场景或整个用例来（部分地）定义的。同时，用例是预算的关键输入。
》用例实现（use-case realization）驱动设计。也就是说，小组设计协作对象和子系统是为了执行或实现用例。
》用例通常会影响用户手册的组织
》功能或系统测试应当符合用例的场景
》为重要用例的最常用场景创建UI "向导" 或快捷方式可以方便执行常用任务
在迭代中如何演化用例和其他规格说明 本节重申了进化式迭代开发的关键思想：规格说明的工作任务在各迭代中的时间量和级别。PPT4展示了一个样例（而非真正的解决方案），表明了如何开发需求的UP策略。
在UP中，提倡在需求讨论会上编写用例。图6-7对完成此项工作提出了时间和地点方面的建议。
何时创建各种UP制品（含用例） PPT5描述了一些UP制品，及其开始和净化的时间表示例。
【在初始阶段如何编写用例？细化阶段如何编写用例？构造阶段如何编写用例？ 研究PPT3，参考P74】