面向对象分析与设计——用例

什么是用例？

• “一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值”（RUP）。
• 描述了从参与者（Actor）角度看系统（黑盒子）做了什么 WHAT。
• 用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。常见错误就是注重于次要的UML用例图，而非重要的用例文本

用例的好处

• 从用户的角度获取操作性需求。
• 对系统的功能进行清晰而一致的描述。
• 系统测试的基础。
• 提供了从功能需求跟踪到系统中真正的类和操作的能力。

定义：参与者、场景、用例

• 参与者（actor） 是某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织，例如：收银员。

• 场景(scenario) 是参与者和系统之间的一系列特定的活动和交互。也称为用例实例（use case instance）。场景是使用系统的一个特定情节或用例的一条执行路径。例如：使用现金成功购买商品的场景，或者由于信用卡付款而拒绝照成的购买失败场景。

• 用例(use case) 就是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。例如：处理退货（主成功场景，交替场景）。

• 用例和用例模型

  • 在需求科目中定义了用例模型（Use-Case Model）。首先，这是所有书面用例的集合；同时，它是系统功能性和环境的模型。 用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。

动机：为什么使用用例

• 需求是很难捕获且易变的

  

• 使工作保持简单的好方法。

• 使领域专家或需求提供者自己编写（或参与编写）用例成为可能。

• 强调了用户的目标和观点。

• 与查询系统特性清单相比更强调以客户为中心。

• 用例的优越性在于能够根据需要对复杂程度和形式化程度进行增减删节。

用例是功能需求吗？用例是：

• 需求，主要是说明系统如何工作的功能性或行为性需求。
• FURPS+中的F。用例强调了”F”(功能性和行为性)。
• 在UP中，用例被推荐作为发现和定义需求的核心机制。
• 用例定义了系统行为的契约。
• 用例是真正的需求（尽管不是所有的需求）。

参与者的三种类型

参与者是任何具有行为的事物，在所讨论系统（System under Discussion,SuD）调用其他系统的服务时，还包括其自身。

• 主要参与者： 具有用户目标，并通过使用SuD的服务完成。通常用来发现驱动用例的用户目标。
• 协助参与者：为SuD提供服务（例如，信息服务）。自动付费授权服务即是一例。协助参与者通常是计算机系统，但也可以是组织或人。协助参与者通常是为了明确外部接口和协议。
  • 为何确定协助参阅者？为了明确外部接口或利益。
• 幕后参与者：在用例行为中具有影响或利益，但不是主要或协助参与者。例如，政府收税机构。通常是为了确保确定并满足所有必要的重要事物。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。

用例的三种形式

摘要－－简洁的一段式概要，通常用于主成功场景。

》何时使用？在早期需求分析过程中，为快速了解主体和范围使用。可能只需要几分钟编写。

非正式－－非正式的段落格式。用几个段落覆盖不同场景。

》何时使用？同上。

详述－－详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。

》何时使用？确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量的具有重要架构和高价值的用例。

详述风格

详述用例是结构化的，它展示更多细节，并且更为深入。最为广泛的格式（alistair.cockburn.us上的模板）：

• 用例名称：以动词开始
• 范围：界定了所要设计的系统
• 级别：用户目标级别或子功能级别（重用，如信用卡支付）。
• 主要参与者：调用系统，使之交付服务
• 涉众及其关注点列表：关注该用例的人及其需要。重要！能够让我们更清楚详细的系统职责
• 前置条件：值得告知读者的，开始前必须为真的条件
• 成功保证：值得告知读者的，成功完成必须满足的条件
• 主成功场景：典型的、无条件的、理想方式的成功场景。§描述了满足涉众关注点的典型成功路径。通常不包括条件或分支。将所有条件和分支延迟到扩展部分进行说明。
• 扩展：成功或失败的替代场景
• 特殊需求：相关的非功能需求
• 技术和数据变元表：不同的I/O方法和数据格式
• 发生频率：影响对实现的调查、测试和时间安排
• 杂项：例如未解决问题。

书上例子——《举例——详述的处理销售》要好好看看理解

用例准则：以无用户界面的本质风格编写用例

• 以本质风格编写用例，摒除用户界面并且关注参与者的意图。
• 具体风格－－用例文本涵盖对用户界面的决策。在早期需求工作中应该避免。
• 举例：假设在管理用户用例中需要标识身份和认证
  • 本质风格：1.管理员标识自己的身份 2.系统对此身份进行验证3. 。。。。。。
  • 具体风格：1.管理员在对话框中输入ID和口令 2.系统对管理员进行验证 3.系统显示“编辑用户”界面 4.……
• 摈除用户界面于考虑之外，集中于意图。
• 编写简洁的用例，删除噪音词汇
• 编写黑盒用例，不对系统内部工作、构件或设计进行描述，通过职责描述系统。
• 采用参与者和参与者目标的视点

如何发现用例(基本过程)

• ①选择系统边界 系统紧紧是软件应用，还是将硬件和作用作为整体，是一个人使用，还是整个组织使用。
• ②寻找主要参与者 通过使用系统的服务实现目标的人或事。
• ③为每个参与者确定他们的目标。
• ④定义满足用户目标的用例，根据其目标对用例命名。通常，用户目标级别的用例和用户目标是一一对应的。

发现用例详细步骤

• 如何发现用例——选择系统边界
  • 系统的边界用来说明构建的用例模型的应用范围。
  • 描述了系统被包含在内的“信封”。
  • 比如一台自助式售货机，系统内功能：售货、供货、提取销售款等功能，自动售货机之外的情况不考虑。
• 如何发现用例——寻找主要参与者和目标
  • 参与者是与系统交换数据的实体。参与者可以是用户，外部的硬件或者另外一个系统。
  • 准则：首先集体讨论主要参与者，因为这样可以为将来的研究建立框架。
  • 什么样的问题有助于寻找参与者和目标：
    • 谁来启动和停止系统。
    • 谁来完成用户管理和安全管理。
    • 谁来完成系统管理。
    • “时间”是管理者吗。因为系统要响应时间事件而完成某些活动。
    • 系统失败时，是否存在监控进程将系统重新启动。
    • 软件升级是如何处理的，是推模式还是拉模式。
    • 除了人作为主要参与者外，还有其他外部的软件或自动机器系统调用该系统的服务吗。
    • 谁来考察系统活动或性能。
    • 谁来考察日志，是否可以远程检索。
    • 系统发生错误或故障时应通知谁。
  • 如何组织参与者和目标
    • 发现结果，将其绘制为用例图，以目标作为用例名称。
    • 或者：首先写出参与者-目标列表，复查并精华之，然后绘制用例图。
• 如何发现用例——定义用例
  • 一般而言，为每一个用户目标定义用例。
  • 定义用例需要交流和参与
  • 用例的粒度问题

利用测试发现有用的用例

老板测试：老板是付钱的人。老板必须看到可量化的价值。

EBP测试：EBP即基本业务过程（Elementary Business Process），定义如下： 一个人于某个时刻在一个地点所执行的行为，用以响应业务事件。该任务能够增加可量化的价值，并且以持久状态留下数据。例如，批准信用卡的信用额或者确定订购的价格。ERP测试与老板测试类似，尤其是对业务价值可量化这一限制而言。用例是在会话过程中完成的任务。用例可能只需几分钟或一个小时就能完成。正如UP的定义，用例增强可观察或可量化的业务价值，由此形成了这样的解释：系统和数据具有稳定和持久状态。

规模测试：用例很少由单独的活动或步骤组成，相反，用例通常应该包括多个步骤

应用UML: 用例图

• 在UML里, 用例图是表达用例和活动者及其之间关系的载体。
• 用例图是模型图，用例图可包含用例，活动者以及它们之间的关系，这些关系可以是：
  • include(包含）
  • extend （扩展）
  • generalization（泛化）
• 用例图的用途是为软件系统、软件子系统、类的动态行为建模。它从两个方面对其建模对象的内容进行描述，即：
  • 描述它们的边界。
  • 对它们进行需求分析。

应用UML: 活动图

• 活动图：有助于使工作流和业务过程可视化的图。
• 因为用例涵盖过程和工作流分析，活动图成为编写用例文本的有用的辅助措施。

过程：在迭代方式中如何使用用例

• 用例是UP和其他众多迭代方法的核心，UP提倡用例驱动开发。
  • 功能需求首先记录在用例（用例模型）中。
  • 用例是迭代计划的重要部分，是预算的关键输入。
  • 用例实现（use-case realization)驱动设计。小组设计协作对象和子系统都是为了执行或实现用例。
  • 用例影响了用户手册和测试。
  • 功能或系统测试应该符合用例的场景。
  • 为重要用例的最常用场景创建UI”向导“或快捷方式可以方便执行常用任务。