36
用例
例如：网站后台管理系统中的会员信息维护用例， 例如：网站后台管理系统中的会员信息维护用例，管理员需要进 行添加会员信息、修改会员信息、删除会员信息等操作。 行添加会员信息、修改会员信息、删除会员信息等操作。
过细的粒度，一般都会导致技术语言的描述， 过细的粒度，一般都会导致技术语言的描述， 而不再是业务语言
29
用例粒度(2) 用例粒度
把步骤当用例
输入用户名 会员
<<include>>
登录 会员
验证用户名和密码
把系统活动当用例
<<include>> 建立数据库连接 << include>> 查询订单
执行SQL语句
3
概述
用例图的作用
用例图是需求分析中的产物， 用例图是需求分析中的产物，主要作用是描述 参与者和用例之间的关系， 参与者和用例之间的关系，帮助开发人员可视 化的了解系统的功能。借助于用例图， 化的了解系统的功能。借助于用例图，系统用 系统分析人员、系统设计人员、 户、系统分析人员、系统设计人员、领域专家 能够以可视化的方式对问题进行探讨， 能够以可视化的方式对问题进行探讨，减少了 大量交流上的障碍，便于对问题达成共识。 大量交流上的障碍，便于对问题达成共识。
第3章 用例图（Use case） 章 用例图（ ）
冯国奇 gqfeng@
1
主要内容
概述 参与者 用例 习题案例
2
概述
用例图的含义
由参与者（ 由参与者（Actor）、 ）、 用例（ 用例（Use Case）以 ） 及它们之间的关系构成 的用于描述系统功能的 视图称为用例图。 视图称为用例图。
Use Cases 把所有这些过程绑到一起
用例图定义和描述了系统的外部可见行为， 用例图定义和描述了系统的外部可见行为， 外部可见行为 是分析、设计直至组装测试的重要依据。 是分析、设计直至组装测试的重要依据。 让用户参与前期的系统分析与设计。 让用户参与前期的系统分析与设计。
5
概述
用例图特点
用例图可视化地表达了系统的需求，具有直观、 用例图可视化地表达了系统的需求，具有直观、 规范等优点，克服了纯文字性说明的不足。 规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能， 用例方法是完全从外部来定义系统功能，它把 需求和设计完全的分离开来。 需求和设计完全的分离开来。我们不用关心系 统内部是如何完成各种功能的， 统内部是如何完成各种功能的，系统对于我们 来说就是一个黑箱子。 来说就是一个黑箱子。
8
参与者
每个参与者可以参与一个或多个用例。 每个参与者可以参与一个或多个用例。 参与者通过交换信息与用例发生交互作用 （因此也与用例所在的系统或类发生了交互 作用） 作用） 参与者的内部实现与用例是不相关的,参与 参与者的内部实现与用例是不相关的 参与 者可以被一组定义它的状态的属性充分描述。 者可以被一组定义它的状态的属性充分描述。
用例A
雇员
用例B
如系统中经理可以参 加雇员的所有用例
用例C 经理
15
用例
用例是外部可见的一个系统功能单元。 用例是外部可见的一个系统功能单元。 这些功能由系统单元所提供， 这些功能由系统单元所提供，并通过一系列 系统单元与一个或多个参与者之间交换的消 息所表达。 息所表达。
16
用例
在模型中,每个用例的执行独立于其他用例 在模型中 每个用例的执行独立于其他用例
19
用例识别方法
可以通过以下问题来寻找用例： 可以通过以下问题来寻找用例：
参与者希望系统提供什么功能？ 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、 参与者是否会读取、创建、修改、删除、存储 系统的某种信息？如果是的话， 系统的某种信息？如果是的话，参与者又是如 何完成这些操作的？ 何完成这些操作的？ 参与者是否会将外部的某些事件通知给系统？ 参与者是否会将外部的某些事件通知给系统？ 系统中发生的事件是否通知参与者？ 系统中发生的事件是否通知参与者？ 什么用例将支持和维护系统？ 什么用例将支持和维护系统？ 是否存在影响系统的外部事件。 是否存在影响系统的外部事件。
9
识别参与者的方法
谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理） 系统需要应付（处理）哪些硬设备 系统需要和哪些外部系统交互 或什么）对系统运行产生的结果（ 谁（或什么）对系统运行产生的结果（值）感兴 趣 时间、 时间、气温等内部外部条件
4、如果扩大边界，让呼 叫中心成为机票预订系 统的一个子系统，机票 购买者通过人工座席、 自动语音及网站预订机 票，那么机票购买者是 actor，人工座席成了业 务工人
14
参与者
参与者之间也可以象类一样存在泛化或者依 赖关系。 赖关系。 在这种泛化关系中， 在这种泛化关系中，一个参与者的抽象描述 可以被一个或多个具体的参与者所共享。 可以被一个或多个具体的参与者所共享。
10
参与者可以非人
如果我开发一个 猪圈自动供食供 水系统，猪的前 蹄触发一个开关 系统就供食或供 水。 这里的Actor 是 小猪。
11
思考：识别参与者？
寻呼台系统：用户如果预定了天气预报，系 统每天定时给他发天气消息；如果当天气温 高于35度，还要提醒用户注意防暑；
在这个叙述里，谁是寻呼台系统的Actor？ 在这个叙述里，谁是寻呼台系统的Actor？
17
用例
用例用一个名字在里面的椭圆表示， 用例用一个名字在里面的椭圆表示，用例和 与它通信的参与者之间用实线连接。 与它通信的参与者之间用实线连接。
将关联属性设置 为navigable即 即 可显示为双向关 联
18
用例
识别用例
任何用例都不能在缺少参与者的情况下独立存 同样， 在。同样，任何参与者也必须要有与之关联的 用例。 用例。所以识别用例的最好方法就是从分析系 统参与者开始， 统参与者开始，在这个过程中往往会发现新的 参与者。 参与者。
30
要点：用例的粒度(3) 要点：用例的粒度
“四轮马车” 四轮马车” 四轮马车
C(Create) R(Read) U(Update) D(Delete) 所有业务最终对会成为 CRUD？ ？ CRUD能为 能为Actor提供 能为 提供 价值？ 价值？ CRUD掩盖业务，锐变 掩盖业务， 掩盖业务 成关系数据库的建模： 成关系数据库的建模：
虽然在具体执行一个用例功能时由于用例之间 共享对象的缘故可能会造成本用例与其他用例 之间有这样或那样的隐含的依赖关系。 之间有这样或那样的隐含的依赖关系。
每一个用例都是一个纵向的功能块， 每一个用例都是一个纵向的功能块，这个功 能块的执行会和其他用例的执行发生混杂。 能块的执行会和其他用例的执行发生混杂。
要点：有意义的目标 要点：
设定查询条件
检索零件 会员
会员 选择零件
23
由参与者发起
24
要点：结果值由系统生成 要点：
吃饭 出纳员
系统需要处理的， 系统需要处理的，由系统生成
25
要点： 要点：业务语言而非技术语言
用户词汇， 用户词汇，而不是技术词汇
如：发票，商品，洗衣机 发票，商品， 而不是：记录，字段， 而不是：记录，字段，COM，C++等 ， 等
管理用户 管理员
32
要点：用例的粒度(4) 要点：用例的粒度
灵活处理CRUD 灵活处理
<<extend>>
管理用户 管理员
增加用户
可以把包含复杂交互的路径独立出去形成用例
33
用例的获得
首先确定actor 首先确定 接下来，开始对actor即业务代表进行访谈 接下来，开始对 即业务代表进行访谈
您对系统有什么期望？ 您对系统有什么期望？ 您打算在这个系统里做些什么事情？ 您打算在这个系统里做些什么事情？ 您做这件事的目的是什么？ 您做这件事的目的是什么？ 您做完这件事希望有一个什么样的结果？ 您做完这件事希望有一个什么样的结果？
34
用例的获得--ATM 用例的获得
客户代表说：我希望这台 客户代表说：我希望这台ATM能支持跨行 能支持跨行 业务，我插入卡片输入密码后， 业务，我插入卡片输入密码后，可以让我选 择是取钱还是存钱；为了方便， 择是取钱还是存钱；为了方便，可以设置一 些默认的存取金额按钮；我可以修改密码， 些默认的存取金额按钮；我可以修改密码， 也可以挂失；还有我希望可以缴纳电话费、 也可以挂失；还有我希望可以缴纳电话费、 水费、电费等费用；为了安全起见， 水费、电费等费用；为了安全起见，ATM 上应该有警示小心骗子的提示条， 上应该有警示小心骗子的提示条，还有摄像 如果输入三次密码错误， 头；如果输入三次密码错误，卡片应当被自 动吞没。 动吞没。
用户,气温,时间都是Actor 用户,气温,时间都是Actor
12
1、机票购买者通过登录网站购买机票，机票购买者 就是actor
2、机票购买者通过呼叫中心，由人工座席操 作订票系统购买机票;人工座席是actor
13
3、如果机票购买者通过呼叫中心的自动语音预订机 票，那么呼叫中心就成了机票预订系统的一个actor
用例图是从用户的角度来描述对软件产品的 用例图是从用户的角度来描述对软件产品的 用户的角度 需求，分析产品的功能和行为 因此， 功能和行为， 需求，分析产品的功能和行为，因此，对整 个软件开发过程而言，用例图是至关重要的。 个软件开发过程而言，用例图是至关重要的。
4
Use Case 对开发的意义
需求 分析和设计 实现 测试
26
要点： 要点：用户观点而非系统观点
处理订票