Chapter 6

用例

目标 为什么使用用例模型 如何寻找用例 使用摘要、非正式和详述用例形式编写用例 用例图

请大家考虑： 需求分析的目标是发现和记录用户需求，那么：

对于书中的 NextGen POS 系统，请考虑一下如何发现和记录用户需求，如何制作一个需求报告的大纲。

Technical people often pay much more attention to an entity relationship diagram or class diagram or a feature list.

特性列表

资源使用状况查询

可用资源查询 指定时间段可用的资源清单，包括资源类型、资源数量等。

资源类型日期范围

实训室使用状况 查询利用指定实训室参加实训、鉴定的培训机构、班级及学员清单等。

实训室编号日期范围

设备使用状况 查询利用指定设备参加实训、鉴定的培训机构、班级及学员清单等。

设备编号日期范围

工器具使用状况 查询指定工器具历次实训、鉴定班级及领用人清单，包括领用时间、归还时间、损坏情况等。

工器具编号日期范围

工件信息查询 指定学员、指定实训 / 鉴定的工件编号等。 学员编号实训 / 鉴定

耗材使用状况 查询指定类型的耗材的历次实训、鉴定班级及领用人清单，包括领用时间、领用数量，合计等。

耗材类型编号日期范围

综合查询

人次数明细表 指定时间段的实训 / 鉴定的人次数等。时间段、设备 / 实训

室 / 项目 / 培训机构 / 中心

人次数统计表 指定时间段内分设备、实训室、项目、培训机构、中心查询预定和实际的人数等。

时间段、设备 / 实训室 / 项目 / 培训机构 / 中心

实训室利用率 指定实训室在指定的日期范围内的利用率等。 实训室编号日期范围

设备完好率查询 指定时间范围内指定设备设备完好率等。 设备 / 实训室 / 中心日期范围

约翰逊 玻璃天堂

Two people see a motorcycle in two ways: as the subsystems that make up the bike and as the things a person can do with the bike.

什么是用例 A use case represents a series of

interactions between an outside entity and the system, which ends by providing business value.

什么是用例 用例是文本形式的情节描述，广泛应用于需求的

发现和记录工作中。 示例：处理销售

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

什么是用例：定义 参与者 (actor)

某些具有行为的事务，可以是人、软硬件系统或组织。 场景 (scenario)

是参与者和系统之间的一系列特定的活动和交互，也称为用例实例 (user case instance)

用例 (use case) 一组相关的成功和失败场景的集合，用来描述如何使

用系统来实现其目标。用例不是什么复杂的概念，但发现需求，并适当编写有相当的困难。

什么是用例：示例 用例：处理退货

主要成功场景：顾客携带商品到收银台退货。收银员使用 POS 系统记录并处理每件退货……

扩展场景： 如果客户之前使用的是信用卡…… 如果系统未在系统中找到商品的标识码……

正常情况和异常情况的分离

什么是用例：用例与需求 用例主要是说明系统如何工作的功能性或行为性

需求，或者说，用例定义了系统行为的契约。 用例也可以用来定义 FURPS+ 中的其他需求。

用例的表示法 用例能够以不同的形式化程度或格式进行编写：

摘要：简洁的一段式摘要，通常用于主成功场景。 用在早期需求分析过程中。

非正式 非正式的段落格式。用几个段落覆盖不同的场景。 也是用在早期需求分析过程中。

详述 编写所有的步骤及各种变化，同时具有补充部分，如前置条件

和成功保证。 在第一次需求讨论会中，详细地编写其中少量 (例如 10%) 的

具有重要意义和高价值的用例。

详细风格用例的组成部分用例名称 以动词开始范围 要设计的系统级别 用户目标或子功能主要参与者 系统的调用者，获取系统的服务涉众及其关注点 关注该用例的人及其需要前置条件 开始前必须为真的条件成功保证 (后置条件 ) 成功完成后必须为真的条件主要成功的场景 典型的，无条件的，理想方式的成功场景扩展 成功场景的替代情况或失败情况特殊需求 相关的非功能性需求可选的技术和数据列表 不同的 I/O技术或数据格式发生频率 该用例发生的频率杂项 例如未决问题

详述风格的处理销售：有何感想？ 收银员的工作原来没有想象中的容易。 图能够表达这段文本的内容吗？ 用例是模型吗？ 特性列表能够表达这段文本的内容吗 ( 老式需求 ) ？

系统应该完成……

详细风格用例的组成部分用例名称 以动词开始范围 要设计的系统级别 用户目标或子功能主要参与者 系统的调用者，获取系统的服务涉众及其关注点 关注该用例的人及其需要前置条件 开始前必须为真的条件成功保证 (后置条件 ) 成功完成后必须为真的条件主要成功的场景 典型的，无条件的，理想方式的成功场景扩展 成功场景的替代情况或失败情况特殊需求 相关的非功能性需求可选的技术和数据列表 不同的 I/O技术或数据格式发生频率 该用例发生的频率杂项 例如未决问题

涉众及其关注点涉众及其关注点

用例应该包含满足所有涉众关注点的事务 例：

收银员：希望能够准确、快速输入，而且没有支付错误…… 销售员：希望自动更新销售提成……

主要成功场景和步骤 主要成功场景和步骤

理想步骤，基本流程 将所有条件和分支延迟到扩展部分进行说明

主要成功场景1. 顾客携带所购商品或服务到收银台通过 POS 机付款2. 收银员开始一次新的交易3. 收银员输入商品 ID4. 系统逐条记录出售的商品……

收银员重复 3-4部，直到商品全部输入5. ……

扩展（或替代流程） 扩展（或替代流程）

成功场景和扩展场景涵盖了系统的功能需求 扩展通常占据了文本的大部分篇幅 是成功场景的分支，反映了例外的情况。

例： 3a. 无效商品 ID:

1. 系统提示错误信息，并拒绝输入该商品标识。 3b. 当有多个商品属于同一类别的时候

1. 收银员可以输入类别的标识和商品的数量

其他格式：两栏变体

准则一：以无用户界面约束的风格编写用例摒弃用户界面表述，关注参与者的意图

例：Login 对比：

本质风格 具体风格1. 管理员标识自己的身份

2. 系统对此身份进行认证

3. ……

1. 管理员在对话框中输入 ID 和口令

2. 系统对此身份进行认证

3. 系统显示”编辑用户”窗口

4. ……

在 GUI 的设计过程中，具体风格的用例可能是一个有用的工具

准则二：编写简洁的用例简洁是大多数领域都追求的目标。

简洁不等于容易 “我认为简单性一直是一个赢家。…找到一个更简单

的解决方案 ---- 毫无疑问，这是我一贯的指导原则” ,

Anders, Turbo Pascal, Delphi 的设计和开发者， C# 的架构师。

准则三：采用参与者的视角 Ivar Jacobson 对用例的定义：

用例是系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察的结果。

要明白谁在使用这个系统，他们为什么要使用这个系统。

系统需要提供什么样的价值

准则四：保持黑盒风格 Black-box use case

不对系统内部工作、构件或设计进行描述，而是通过职责来描述系统。

如何发现用例步骤：

选择系统边界 确定主要参与者 确定每个主要参与者的目标 定义满足用户目标的用例，根据其目标对用例命名。

有效用例的测试 哪些用例是有效的：

与供应商进行合同谈判 处理退货 登录 (Login)

老板测试 EBP测试

Elementary Business Process:该任务能够增加可量化的业务价值，并且以持久状态留下数据。

规模测试 用例通常需要包括多个步骤，在详述格式下。需要数页的文本。

UML Use Case Diagram初学者通常会犯的错误是，将用例图和用例关系

作为重点。 用例图和用例关系在编写用例的工作中是次要的

。用例是文本文档，编写用例意味着编写文本。绘制用例图的准则是：绘制简单的用例图，并与

参与者 -目标列表关联。

UML: Use Cases Diagram

Use Case

Actor

UML: Use Cases Diagram

UML: Include Relationship

Process Sale

Cashier

Handle Creditpayment

POST

Handle Cashpayment

Handle Checkpayment

<<include>><<include>><<include>>

其它描述需求的方法 UML 活动图

UML 包含一种有助于使得工作流和业务过程可视化的图：活动图，他能够成为编写用例文本有用的辅助措施。

特征列表 有些系统使用特征列表可能更合适，如服务器，数据

库，编译器等。

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

小结 什么是用例，用用例发现和记录需求有什么优点 用例的三种格式 书写用例的注意事项 用例图