第6章 用例

本文为《UML和模式应用(原书第3版)》读书笔记

---

用例是文本形式的情节描述，广泛应用于需求的发现和记录工作中。

示例

顾客携带商品到收银台，收银员使用POS系统记录每件商品，系统连续显示累计总额，并逐行显示细目。顾客输入支付信息，系统对支付信息进行验证和记录。系统更新库存信息，顾客从系统得到购物小票，然后携带商品离开。

参与者、场景和用例

• 参与者是某些具有行为的事物，可以是人、计算机系统或组织，例如收银员。
• 场景是参与者和系统之间的一系列特定的活动和交互，也称为用例实例。场景是使用系统的一个特定情节或用例的一条执行路径。例如使用现金成功购买商品的场景，或使用信用卡付款被拒造成购买失败的场景。
• 用例就是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现其目标。
• 例如处理退货
  
  • 成功场景：收银员使用POS系统记录并处理每件退货。
  • 交替场景：客户之前使用信用卡付款，信用卡拒绝退款；在系统未找到商品标识码；与外部记账系统通讯失败等。
• 一组用例的实例，其中每一个都是系统执行的一系列活动，这些活动产生了对某个参与者而言可观察的返回值【RUP】

用例和用例模型

• 用例模型是所有书面用例的集合，同时也是系统功能性和环境的模型。
• 用例是文本文档，而不是图形，用例模型主要是编写文本的活动，而非制图。
• 用例有利于用户参与项目，比如领域专家或需求提供方可以自己编写用例，而且用例强调了用户的目标和观点。
• 用例的优越性在于，能够根据需要对复杂程度和形式化程度进行增减调节。
• 用例就是需求，主要是说明系统如何工作的功能性或行为性需求。
• 在统一过程和其他现代方法中，用例被推荐为发现和定义需求的核心机制。
• 用例的主要思想：为功能性需求编写用例，从而降低详细的老式特性列表的重要性或减少这种列表的使用。

参与者的三种类型

• 参与者是任何具有行为的事物。
• 主要参与者，具有用户目标，并通过使用系统的服务完成。例如收银员。
• 协助参与者，为系统提供服务，一般是计算机系统。比如说自动付费服务授权。
• 幕后参与者，在用例行为中具有影响或利益，但不是主要或协助参与者。例如政府税收机构。

表示法：用例的三种常用形式

• 摘要，简洁的一段式概要，通常用于祝成功场景。例如示例中的处理销售。
• 非正式，非正式的段落格式，用几个不同的段落覆盖不同场景。例如示例中的处理退货。
• 详述，详细编写所有步骤及各种变化，同时具有补充部分，比如前置条件和保证成功。

示例：详述风格的处理销售

• 详述用例是结构化的，它展示了更多的细节，并且更为深入。
• 在迭代和进化式UP需求分析中，第一次需求讨论会应该以这种形式编写10%的关键用例，然后对这10%中最具有重要架构意义的用例或场景进行设计和编程。
• 详细用例格式的模板采用以下风格，是目前使用最为广泛的格式：
  
  • 用例名称：以动词开始。
  • 范围：范围界定了索要设计的系统。通常用例描述的是对一个软件系统（或硬件加软件）的使用，这种情况下称之为系统用例。在更广义的范围上，用例也能够描述顾客和有关人员如何使用业务。这种企业级的过程描述被称为业务用例。
  • 级别：用例主要分为用户目标级别或子功能级别。用户目标级别是通常所使用的级别，描述了实现主要参与者目标的场景，该级别大致相当于业务流程工程中的基本业务流程。子功能级别用例支持用户目标所需要的自步骤，当若干常规用例共享重复的自步骤时，将其分离出来，创建为子功能级别用例（以避免重复公共的文本），比如信用卡支付，该用例可以被许多常规用例所共享。
  • 主要参与者：调用系统服务来完成目标的参与者。
  • 涉众及其关注点列表：该列表建议并界定了系统必须要做的工作。用例应该包含满足所有涉众关注点的事物，在编写用例其余部分之前就确定涉众及其关注点，能够让我们更加清楚地了解详细的系统职责。从涉众及其关注点的角度出发，能够为发现并记录所有行为需求提供彻底、系统的过程。
  • 前置条件：给出在用例中场景开始之前必须永远为真的条件。通常前置条件隐含已经成功完成的其他用例场景，例如“登录”。注意有些条件也必须为真，但是不值得编写出来，例如“系统有电力供应”。前置条件传达的是编写者认为应该引起读者警惕的那些值得注意的假设。
  • 成功保证：给出用例成功结束后必须为真的事物，包括主成功场景及其替代路径。该保证应该满足所有涉众的需求。
  • 主成功场景和步骤（或基本流程）：也被称为“理想路径”场景，或“基本流程”及“典型流程”。它描述了满足涉众关注点的典型成功路径，要注意的是，它通常不包括任何条件或分支，保持一定的连贯性，并且将所有条件处理都推延至扩展部分，这样的做法更易于理解和扩展。场景记录三种步骤：1.参与者之间的交互；2.确认过程（通常由系统来完成）；3.系统完成的状态变更（例如记录或更改某事物）；
  • 扩展：扩展是重要的并通常占据了文本的大部分篇幅。扩展部分描述了其他所有场景或分支，包括成功和失败路径。在整个用例编写中，理想路径与扩展路径相结合应该满足“几乎”所有涉众所关注的问题。但是有些关注问题最好是作为非功能性需求在补充规格说明中描述，比如顾客要求显示商品描述和价格。扩展由两部分组成：条件和处理。尽可能用系统内给或参与者能够检测到的事物作为条件，例如，系统检测到与外部税务计算系统服务的通讯故障和外部税务计算系统工作不正常，前一种比较好，因为那个是系统能够检测的条件，而后一种只是推断。
  • 特殊需求：相关的非功能性需求；将所有非功能性需求集中于补充规范规格说明中，对于内容管理、可理解性和可读性而言更为有效，因为在架构分析时通常将这些需求作为整体来考虑。
  • 技术和数据变元表：不同的I/O方法和数据格式，在需求分析中发现的一些技术变元，这些变元是关于必须如何实现系统的，而不是实现系统的哪些功能。
  • 发生频率：影响对实现的调查、测试和时间安排；
  • 杂项：例如未决问题；

以下是基于以上模板的相关示例：

范围：NextGen POS 应用（销售时点信息系统）
级别：用户目标
主要参与者：收银员
涉众及其关注点：

• 收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收贷款，将从薪水中扣除。
• 售货员：希望自动更新销售提成。
• 顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。
• 公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即使在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新账务和库存信息。
• 经理：希望能够快速地执行超控操作，并易于更正收银员的不当操作。
• 政府税收代理：希望能从每笔交易中抽取税金，可能存在多级税务代理，比如国家级、省级、市级。
• 支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。

前置条件：收银员必须经过确认和认证。
成功保证（或后置条件）：存储销售信息。准确计算税金。更新账务和库存信息。记录提成。生成票据。记录支付授权的批准。
主成功场景（或基本流程）：

1. 顾客携带所购商品或服务到收银台通过POS机付款。
2. 收银员开始一次新的销售交易。
3. 收银员输入商品条码。
4. 系统逐条记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。
   收银员重复3~4步骤，直到输入结束。
5. 系统显示总额。
6. 收银员告知顾客总额，并请顾客付款。
7. 顾客付款，系统处理支付。
8. 系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。
9. 系统打印票据。
10. 顾客携带商品和票据离开。

扩展（或替代流程）：例如系统在某一步失败、无效的商品、顾客告知免税状况、需要手工输入类别和价格、顾客要求取消销售交易等。这些情况和步骤需要结合实际的场景进行详细的描述，例如：

在主成功场景的第3步，出现无效商品ID，第一个描述条件及响应扩展被标记为“3a”，第二个标记为“3b”，以此类推。
  3a.无效商品ID：
  1.系统提示错误并拒绝输入该标识。
  3b.多个商品属于同一类别时，不必记录每个商品的唯一标识：

当一组步骤中都出现相同条件时，可以如下表示：
  3-6a.顾客要求收银员从所购商品中去掉一项：
  1.收银员输入商品ID并将其删除。
  2.系统删除该项目并显示更新后的累计额。

在任何或大多数步骤都可能发生的扩展条件，可以用“*a”和“*b”这样的标记，另外在复杂的扩展中还可以另外使用单独的用例来表达该扩展，即扩展是可以嵌套的。
  *a. 系统在任意时刻失败：
  保证所有交易的敏感状态和时间能够从场景的任何一步中完全恢复。
  1.收银员重启系统，登录，请求恢复上次状态。
  2.系统重建上次状态。
    2a.系统在恢复过程中检测到异常：
    1.系统向收银员提示错误，记录此错误，并进入一个初始状态。
    2.收银员开始一次新的销售交易。

特殊要求：使用大尺寸平面显示器触摸屏、90%的信用卡授权响应时间小于30秒、支持文本显示的语言国际化等。
技术与数据变元表：商品ID可以用扫描枪输入或键盘输入、信用卡账户信息可以用读卡器或键盘输入等。
发生频率：可能会不断地发生。
未决问题：税法如何变化、研究远程服务的恢复问题、顾客是否可以直接使用读卡器，还是必须由收银员完成等。

准则

• 以无用户界面约束的本质风格编写用例：*以本质风格编写用例，摒除用户界面并且关注参与者的意图。*例如表述为“登录”的这一个目标，收银员可能会想象有图形界面、对话框、用户名和密码。这是实现目标的一种机制，但不是目标本身。通过对目标层次的研究，系统分析员会发现与实现机制无关的目标，比如标识自己身份并得到认证、或者更为高层的目标：防盗。这种对根源目标的发现过程能够扩展视野，以促成新的和改进的解决方案，例如如果目标是识别身份和认证，那么为何不直接使用生物信息读取装置来实现这一功能，而这一问题可能涉及到可用性分析，比如说手指是否粘有油脂，有没有手指等。与之相对应的是具体风格，在早期需求工作中应该避免这样的风格，具体用例的风格包括但不限于窗口截屏、窗口导航讨论、交互小部件的操作等。
• 编写简洁的用例：尽量减少词汇。
• 编写黑盒用例：黑盒用例不对系统内部工作、构件或设计进行描述，它通过职责来描述系统。分析与设计的区别在于“什么”和“如何”的差异，在需求分析中应避免进行“如何”的决策，而是规定系统的外部行为。
• 采用参与者和参与者目标的视点：强调了需求分析的两个态度，一个是关注系统的用户或参与者来编写需求，询问其目标和典型情况，另一个是关注理解参与者所考虑的有价值结果。
• 如何发现用例：
  
  • 选择系统边界。系统仅仅是软件还是软硬结合，是一个人还是整个组织在使用。对于本案例，POS系统是要被设计的系统，任何该系统之外的事物都在系统边界之外，包括收银员、支付授权服务等。
  • 确定主要参与者。在本案例的处理销售用例中，主要参与者是收银员而不是顾客，因为在POS系统的边界出发，系统所服务的目标是受过训练的收银员，以实现“专业用户”的目标。
  • 确定每个主要参与者的目标。通过使用系统的服务实现其目标的那些人或事物。谁来启动和停止系统？谁来完成用户管理和安全管理？谁来完成系统管理？你在做什么（比较像是在反映当前的解决方案与过程，以及期间的复杂因素），你的目标是什么（能够开阔思路以形成新的和改进的结局方案，能够集中于增加业务价值并且能够触及涉众想从系统中得到的核心价值）。
  • 定义满足用户目标的用例，根据其目标对用例命名，用例名称应使用动词开头。

用例图

• 用例图用于描述用例名称和参与者及其之间的关系。
• 简单的用例图能够为系统提供简洁可视的语境图，能够阐述外部参与者及其对系统的使用。
• 用例图能够展示系统边界、位于边界之外的事物以及系统如何被使用。
• 应注重编写文本，而不是用例图和用例关系。

由于该书认为用例图只是辅佐理解用例，因此在用例图上并没有讲的很详细，以下是目前详细的用例图画法：
　用例图所包含的元素如下：
1. 参与者(Actor)
　　表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2. 用例(Use Case)
　　用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
3. 子系统(Subsystem)
　　用来展示系统的一部分功能，这部分功能联系紧密。
　　
4. 关系
　　用例图中涉及的关系有：关联、泛化、包含、扩展。

a. 关联(Association)
　　表示参与者与用例之间的通信，任何一方都可发送或接受消息。
　　【箭头指向】：指向消息接收方
　　
b. 泛化(Inheritance)
　　就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
　　【箭头指向】：指向父用例

c. 包含(Include)
　　包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
　　【箭头指向】：指向分解出来的功能用例
　　
d. 扩展(Extend)
　　扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
　　【箭头指向】：指向基础用例
　　
e. 依赖(Dependency)
　　以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。
　　【箭头指向】：指向被依赖项
　　
　　
包含(include)、扩展(extend)、泛化(Inheritance) 的区别：
　　条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；
　　直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。
　　对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
　　对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；
　　

活动图

用例涵盖过程和工作流分析，所以活动图能够成为编写用例文本的有用的辅助措施。

容许高阶系统特性列表

• 在设想文档中加入简介的高阶特性列表有助于概括系统的功能性，该列表也称为系统特性列表。系统特性列表独立于用例视图，简要地概括了功能性。
• 有时某些应用迫切需要特性驱动的观点，例如对于应用服务器、数据库产品和其他中间件或后台系统而言，首要考虑的是特性（“比如需要在下一版本中支持web Services”）。

总结

• 在初始阶段如何编写用例：不以详述形式编写所有用例，假设有为期两天的需求讨论会，在开始的时候主要工作是确定目标和涉众，并且推测项目的范围，使用工具编写、显示 参与者-目标-用例列表，绘制用例语境图。几个小时之后，大概确定20个用例的名称，以摘要形式编写大部分需要关注的、复杂的、具有风险的用例，每个用例平均话费两分钟时间编写，小组开始对系统的功能性达成共识。然后以详述形式重新编写其中10%~20%的用例，这些用例代表复杂的核心功能、需要构建核心架构或者在某些方面极具风险，通过对具有影响力的用例所完成的小范围深入调查，小组能够进行略为深入的研究，以获取对项目规模、复杂度、隐藏风险的理解。
• 在细化阶段如何编写用例：该阶段含有多次时间定量的迭代，在这些迭代中，逐步地构建具有风险、高价值或具有重要架构意义的部分系统，同时确定需求的主题。由于具体编程步骤的反馈会影响和干预小组对需求的理解，对需求的迭代是可适应的。每次迭代都可以有一个为期两天的需求讨论会，但是并不是要在每个讨论会上调查所有用例，而是讨论具有优先级、最重要的用例。在随后精化用户目标和用例列表，以详述形式编写和重新编写更多的用例，在细化阶段结束时，将详细编写80%~90%的用例。注意该阶段所涉及对部分系统的编程，因此在该阶段结束时，除了有更详细的用例定义外，还应该有一些可执行的软件。
• 在构造阶段如何编写用例：在细化阶段，一旦解决了那些具有风险的和不稳定的核心问题，那么在由时间定量的迭代组成的构造阶段中，则侧重于完成系统。在这一阶段中，可能还要编写一些次要的用例，还会举行需求讨论会，但是次数会大大少于细化阶段。