文档介绍：系统分析师UML用例实战》介绍如何通过用例掌握UML。《系统分析师UML用例实战》的案例基于Wesley和Richard两个角色叙述，从两人开始接到一个书店系统的项目，到动手建立用例模型，并且应用用例技术来估算工时，系统记述了UML用例的应如机票购买者通过呼叫中心,由人工座席操作订票系统购买机票
--------人工座席是系统参与者
--------机票购买者是呼叫中心的参与者
案例三:机票预订系统(续)
?
业务参与者
系统参与者
案例三:机票预订系统(续)
,让呼叫中心称为机票预订系统的一个子系统,并且夹着机票购买者可以自主选择通过人工座席,自动语音还是网站预订机票呢?
业务工人
如何区分参与者还是工人呢?
人工座席属于哪一类?
参与者的角色
角色类型
行为
启动者
初始化用例
外部服务者
在用例中向系统提供服务
接收者
从用例接收信息
帮助者（代理,业务工人）
为其他参与者与系统的交互提供帮助
用例建模
用例视图应该包含一组定义了该系统完整功能的用例，或者至少定义了当前迭代所规定功能的用例
用例视图应该是客户、最终用户、领域专家、测试人员和任何其他涉及系统的人员，不需要详细了解系统结构和实现就容易理解的
用例就是需求
F
关键问题
用例分析的关键是专注于“怎样才能使系统为用户提供可观察的数值，或帮助用户实现他们的目标，而不是简单认为系统需求就是列举系统的特征和功能”
黑箱用例
描述系统具有哪些职责
做什么
用例特征
用例是相对独立的
用例的执行结构对参与者来说是可观测和有意义的
用例的获得
用例准备工作：
发现参与者
用例的获得（续）
引导业务代表来获取用例：
您对系统有什么期望
您打算在这个系统里做些什么事情
您做这件事的目的是什么？
您做完这件事希望有一个什么样的结果？
用例的获得（续）
P19 表1-9用例的问题列表
如果我们是“顾客”，我们会怎么使用系统？什么时候我们会开始使用系统？
画流程，看看顾客使用系统的流程，然后再来核对，看看需要增加什么用例
UML活动图
注意，画UML活动图只是为了辅助我们抓用例，所以不要陷入细节中。
用例的目标和范围
发现用例——确定用例的目标和范围
用例应该在什么级别和范围上表述呢？
怎样发现用例？
谈判一个供货合同
处理返回值
登录
在游戏板上移动棋子
是否是有效的用例?
可以认为这些都是用例，但它们处于不同的级别，依赖于系统边界、参与者和目标。
与其泛泛地问“什么是有效的用例？”，不如更直接地问：“对应用的需求分析来说，在什么级别上描述用例最有帮助？
测试用例
老板测试
规模测试
ＥＢＰ测试
测试用例（续）
老板测试
用例的执行结构对参与者来说是可观测和有意义的
如果该用例不同通过老板测试，这意味着该用例与达到可量化价值的结果没有太大关系——“也许是更低级别的用例”
登录
填写取款单
测试用例（续）
规模测试
用例很少由单独的活动或步骤组成
在游戏板上移动棋子
输入商品编号
测试用例（续）
EBP指导原则
——EBP用例：对计算机应用进行需求分析的时候，应关注于“基本业务过程”(EBP)级别的用例
一个主要成功场景会包含5-10个小步骤
用例也不是一个需要好几天和很多对话才能完成的工作
它是能够在一个对话、几分钟或一个小时的时间内就可以完成的任务。
用例强调了能够增加可见的或可度量的业务价值
EBP级别上的用例
一个EBP级别上的用例通常被称为一个用户目标级别上的用例，以强调用例应该帮助系统的用户来实现自己的目标
找出用户的目标
为每个目标定义一个用例
你想做什么？
你的目标是什么？
解决方案和过程
激发新的、改进方案的想象
增加可见的或可以度量的业务价值
对EBP原则的合理违反
尽管一个应用的“基本”用例应该满足EBP原则，但我们经常会创建一些单独的“子”用例来表示基本用例中的子任务或步骤。用例有时候不必符合EBP原则。EBP的指导原则只在对应用进行需求分析时用来寻找主要用例，也即命名、写出主要用例。
例子:“信用卡支付”。
用例的其他特征
必须由一个参与者发起
用例必须以动宾形式出现的
一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元和部署单元
ATM吐钞
统计
喝
用例的粒度
用例的粒度以