UML需求建模-用例描述

错误。
需求建模
5
如何写用例
火龙果 整理 uml.org.cn
也称之为用况，是一个描述型文档，用来
描述一个参与者（一个外部的主动者）使 用系统完成某个过程时的事件发生顺序。
通俗而言，用例就是如何使用系统来达到
目标的一组情节，其本质是通过写出多种 使用系统的情节来发现和记录功能性需求
简单有效
售和付款信息发送到外部的记账系统 （进行记账）和库存系统（记录销售信息
和更新库存）
8.顾客带着商品和收据离开
扩展（替代/可选流程）
火龙果 整理 uml.org.cn
说明了所有其他的场景或分支，无论是成
功的场景还是失败的场景
扩展场景是从主要成功场景中分支出来的，
因此应该遵从主要成功场景的标记方式
为汽车加油
需求建模
32
扩展（extend）
火龙果 整理 uml.org.cn
Take Trip可能有多个可选的场景。这些不同的可选行为可以
增加到基本场景中。 如：在一次长途旅行中，可能要停车，然后“Eat Meal(就 餐)”。这个可选的场景可用“<<extend>>”标记表示，如 图所示。 旅行
火龙果 整理 uml.org.cn
需求建模——用例描述
火龙果 整理 uml.org.cn
案例研究： 销售点终端系统
销售点终端系统
销售点终端系统是一种计算机应用，能够记
火龙果 整理 uml.org.cn
录销售信息和处理支付过程。
火龙果 整理 uml.org.cn
简单用例图
用例图显示了系 统的一组用例， 用例的参与者以 及用例和参与者 之间的关系。
人员(例如顾客、业务发起人)打交道时的一种理想描述形式。
用文本形式描述用例也有一个严重的缺陷。这样描述的用例与
其他所有文本形式的规格说明一样：规格说明越来越复杂时， 其中的各种条目之间的关系和信息交互将变得难以理解。

解决的办法：用UML顺序图描述用例 这也正是用UML顺序图描述用例的长处所在。
怎么开始？
火龙果 整理 uml.org.cn
讲“故事”——高层用例 写出多种使用系统的情节——由一两个人写出一个简 短而完整的描述，如：
用例：购买商品 起点。。。终点 参与者：顾客（发起者）、收银员 类型：主要的用例（次要的、可任选的） 描述：顾客带着所要购买的商品来到收款 处。收银员记录下商品信息并收款。付款 结束后，顾客带着所购买的商品离开。
火龙果 整理 uml.org.cn
用例描绘的场景(或事件流)展示了参与者如何
使用系统。
典型地，一个用例应该包含一个主事件流和
其他不同的可选场景，就像地图描绘了主路 线同时也展示了其他可选择的路线。
描述用例(续)
火龙果 整理 uml.org.cn
用例描述可能包含大量信息，
需要某种系统的方法来记录这 些信息 UML没有定义一种描述用例的 标准形式 许多开发人员定义了用例描述 的模板
归档用例
火龙果 整理 uml.org.cn
基本用例 每一个用例必须包含这样一些细节， 这些细节告诉人们需要完成哪些步 骤才能实现这个用例的功能 基本功能 所有可选方案 异常情况 进入用例之前以及退出用例时必 须正确的一切
一个用例格式模版
主要参与者
火龙果 整理 uml.org.cn
为汽车加油
就餐
34
需求建模
火龙果 整理 uml.org.cn
购买商品
登 录
收银员 顾客
退还商品
火龙果 整理 uml.org.cn
用例的关键特征
用例描述的系统行为是具体的、完整的场景。
用例描述的不是一个场景的片段，不是一个场景的
具体步骤，也不是应用的具体功能。
你不能将用例分解为一些小的模块，然后将这些小
模块称之为用例。
注意：利用用例进行系统的功能分解是一个常见的
需求建模
29
火龙果 整理 uml.org.cn
用例之间的关系
包含（include）
用例不仅仅与参与者之间存在交互关系，一个用例还可以与其
他用例存在关系。

假设你正在开发一个与开车旅行有关的用例。为了讨论的方 便，假设“Take Trip(旅行)”是一个用例，它的流包括旅行 规划、为汽车加油、驶往目的地、观光和驾车返回。这个用 例可能包含多个可选的场景。
寻找扩展路径的方法
方法一：沿着基本 方法二：用以下大类
火龙果 整理 uml.org.cn
路径一条一条地找， 并且考虑：
在这个点上还可以执
去发现可选路径
行别的活动吗？ 在这个点上有没有什 么可能出错的？ 有什么随时可能发生 的行为吗？
火龙果 整理 uml.org.cn
描述指导原则：以系统或参与者能够监测到的某事物作
文本形式的用例规格说明具有许多优点：
1. 2.
简单易用，不需要CASE工具的支持。 不需要了解有关软件开发方法学的知识。
3.
4. 5.
不需要培训。
便于携带。 可以在任何时间任何地点编写用例。
6.
需求建模
以顾客能够理解的自然语言描述用例。
28
火龙果 整理 uml.org.cn
文本形式的用例规格说明所具有的上述优点使之成为与非技术
为汽车加油
就餐
需求建模
33
火龙果 整理 uml.org.cn
扩展(extend)关联的含义是基用例(如图中的"旅行")可以通过可
选的扩展用例(extending use case，如图中的"就餐")加以扩 展。 一个扩展用例事实上改变了基用例的事件流。 扩展用例的行为是否被执行要取决于主事件流中的判定点。 在本例中，当基场景到达Eat Meal选择项代表的扩展点 (extension point)时，司机必须决定他是否想要进餐。如果是， 则扩展用例Eat Meal将被执行。如果不是，则沿基用例的事件 流继续执行。 旅行
前置和后置条件表示用例开始和结束会发
生什么
前置：规定了在用例中的一个场景开始之前
必须为“真”的条件 后置：规定了在用例中的一个场景成功结束 后必须为“真”的条件
前置条件：收银员必须已经被确认和认证 存储销售信息 生成收据 更新账务和库存 这一“保证”应该满足 记录提成 所有项目相关人员 的需要 准确计算税金 记录支付授权的批准
扩展（替代/可选流程）
火龙果 整理 uml.org.cn
说明了所有其他的场景或分支，无论是成功的场景
还是失败的场景
扩展场景是从主要成功场景中分支出来的，因此应该遵
从主要成功场景的标记方式
3.收银员输入商品标识
扩展
一个扩展以两个部分 组成：条件和处理
3a.无效的商品ID 1.系统指示错误并拒绝输入 2.收银员响应该错误，重新输入 3b.有多个具有相同商品类别的信息（如5条A式毛巾），不需要 跟踪每个商品的唯一身份 1.收银员可以输入商品类别的标识和数量

在你开发其他用例的过程中，你会发现有一个活动在每个场
景中都会出现，那就是“Fuel Vehcile(为汽车加油)”。
需求建模
30
火龙果 整理 uml.org.cn

为汽车加油的动作在每个用例中是相同的。这种公共的行为 可以用一种特殊的关联表示，如图所示，在一个带箭头的虚 线上附加一个“<<include>>”标记。
主要的成功场景和步骤（基本路径）
火龙果 整理 uml.org.cn
它描述了能够满足项目相关人员兴趣的典
型的成功路径
参与者的交互 一个验证动作 由系统完成的状态改变
（第一个步骤用来指示一个用来开始场景的触 发事件）
Happy Path
处理销售基本路径
参与者的动作 1.当顾客携带购买的商品到达销 售终端时，用例开始 2.收银员录入商品的商品号 系统响应

注意：这一部分不应包含用来表述不同情况下不同行 为的多个步骤，如果有必要，将这些步骤记录在“扩展” 部分
火龙果 整理 uml.org.cn
用例规格说明力图简洁，限制在几页的篇幅内。用例规格说明的目
的是紧凑地说明用例的事件流。如果篇幅太大，那么用例要做的事
情就会过多，或者在编写用例时可能使你在不重要的可选流上花费 过多的精力。
火龙果 整理 uml.org.cn
3.系统记录单件商品，并显示该商品的描述、 价格和累加值。价格可以根据一套定价规格来 计算
收银员重复3-4步
4. ，输入完商品信息后，向销售 终端发出提示，提示商品信息录 入完毕 6.收银员录入顾客所付金额 5.系统记录和显示该顾客的商品价值总额，并 计算税金 7.系统显示应找金额，打印付款收据；并将销
旅行
为汽车加油
需求建模
31
火龙果 整理 uml.org.cn
包含(include)关联的含义是包含用例(include use case，如
图中的Fuel Vehicle)嵌入在基用例(base use case，如图中 的Take Trip)的流中。 包含用例是可重用的用例——多个用例的公共用例。 尽管包含用例是公共用例，但它同样是强制性的。 在这个例子中，如果没有它的包含用例Fuel Vehicle，则基 用例Take Trip是不完整的。在基用例的场景中，当基用例的 执行到达包含用例的包含点(inclusion point)时，包含用例 被执行。 旅行
例如：对于销售点终端系统来说，一些可能的参 与者和他们发起的过程有：
参与者 事件
销售员
顾客
登录 用现金结算 购买商品 退还商品
项目相关人员及其兴趣
火龙果 整理 uml.org.cn
用例应该包含满足了所有的项目相关人员兴趣的内
容 以项目相关人员的兴趣作为视点来观察，会为我们 提供一种彻底的、系统化的程序，用来发现和记录 所有必需的行为
为条件
5.系统显示总值并计算税金
方式1
5a.系统检测到与外部的税金计算系统的通信故障
方式2
5b. 外部的税金计算系统工作不正常
？
推测
火龙果 整理 uml.org.cn
扩展处理也可以包含一系列步骤：
扩展
3-6a.顾客要求收银员从已输入的商品中去掉一个商品 1.收银员输入商品标识并将其删除 2.系统显示更新后的累加值
ห้องสมุดไป่ตู้
顾客要求兑换账户积分
顾客要求其它的支付方式 顾客要求使用优惠券 顾客索要赠品票据
特殊要求
火龙果 整理 uml.org.cn
特殊要求：如果有一些与此用例有关的非功能需求（象质
量属性或约束条件），那么将它们和用例记录在一起。
FURPS+模型
在大型平板显示器上的触摸屏界面。文本信息要能够
项目相关人员及其兴趣
前置条件 成功后的保证（后置条件） 主要成功场景（或基本流程） 扩展（或替代流程） 特殊需求 技术与数据的变化列表
销售点终端的主要参与者
火龙果 整理 uml.org.cn
调用系统服务来完成目标的主要参
与者
收银员 顾客
？
火龙果 整理 uml.org.cn
描述用例
用例描述了系统和它的用户之间在一
火龙果 整理 uml.org.cn
定层次上的完整的交互 在用例的不同实例中将发生什么样的 细节，会在很多方面有所不同 一个用例实例中可能会出现差错，将 不能达到原来的目的 一个用例的完整描述必须指明，在用 例所有可能的实例中可能发生什么
描述用例
顾客（发起者） 售货员
购买商品
收银员
公司 政府税务机关 支付授权服务
火龙果 整理 uml.org.cn
确定用例——EBP级别的用例
一个好的用例为参与者产生一种可以估量的价值
结果 描述参与者想要系统完成的事情
火龙果 整理 uml.org.cn
前置条件和后置条件
在1米之外看清 90%的信用卡授权机构的响应应该在30秒收到 ……
技术和数据的变化列表
火龙果 整理 uml.org.cn
技术和数据的变化列表：系统通常有一些技术上的变化是
关于“应该怎么做”，而不是“应该做什么”，需要在用 例中将这种变化记录下来。
“这个POS系统必须支持信用卡帐号的读卡器 输入和键盘输入”
3－6b.顾客要求取消销售交易 1.收银员在系统中取消销售交易 2.系统开始新的销售 3－6c.收银员延迟销售交易 1.系统记录销售交易信息，使其能够在任何登录中恢 复操作 2.系统显示用来恢复销售交易的“延迟票据”，包括 商品项目和销售交易ID
其它的一些扩展
顾客声称他们符合打折条件
火龙果 整理 uml.org.cn