用例规约
... 术语表
Name of the Use Case (用例的名字)
Description (描述) Actor(s) (参与者) Flow of events (事件流)
Basic flow (常规流) Event 1 (事件) Event 2
…… Alternate flow (备选流) Pre-conditions (前置条件) Post-conditions (后置条件) ……
采用“基于用例的方法”来识别和获取需 求，是从外部的角度来看系统功能，建立 系统的Use case模型。
Use case模型由若干Use case图组成，描述外 部执行者（Actor）所理解的系统功能，即 待开发系统的功能需求。
在Use case图中，Use case（用例）表示一个 子系统，或者一个对立的功能。
识别用例行为中的点 ，指明扩展时机的点。
Extension Point Print
Withdraw <<extend>>
Extension Point Print
Print Receipt
提款(Withdraw)用 例记载了一个打印 的扩展点,打印收据 (Print Receipt)的 行为会被插入到打 印扩展点。
第13章 基于用例的需 求分析方法
软件学院 代飞
2013.春
基于用例的需求分析方法
1992年由Jacobson提出了Use case的概念及 可视化的表示方法-Use case图，并加入由 他提出的面向对象的软件工程（OOSE）。
Use case的概念收到了IT界的欢迎，被广泛 应用到了面向对象的系统分析中。基于用 例的需求方法，已成为面向对象分析方法 的主流。
4 后置条件：如果用例执行成功，该读者的借书记录被 更新，否则，系统状态不变。
确定用例
确定用例从参与者角度向系统提问， 确定可能的服务。
角色需要系统做什么？从系统获得那些功能？
角色需要读取、产生、删除、修改、存储系统 中什么信息？
角色需要知道系统发生了什么事件？这些事件 做些什么？
系统提供给角色的信息是否简化了？
参与者之间的关系
actor 1
客户
保险登 actor 2 记客户
参与者之间的泛化(Generalization)关系
电话登 记客户
普通用户 管理员
常规操作 管理操作
系统维护员 配置操作
用户
常规操作
管理员 管理操作
系统维护员
配置操作
用例之间的关系：
用例1
(1) 泛化(generalization )
<<include>>
<<extend>> 查询读者
登记 <<extend>> 借书
查询读书
<<extend>>
参加考试
补考
34
例:
订货系统
<<include>>
<<include>>
提供客户数据 订货项目
订货系统 <<extend>> 请求目录
查询 存款
<<extend>> 打印收据
<<include>>
发起参与者(initiator actor) 参加参与者(participating actor)
11
确定参与者(actor)
你系统的主要客户是谁? 谁从你的系统取得的信息?使用信息? 谁为你的系统提供信息？删除信息？ 谁安装、操作、关闭系统(次要角色)? 系统从什么地方得到信息? 其他系统与该系统交互信息是什么? 在某一个预定时间，是否有什么事情
用例图的主要基本元素
执行者（角色）：是系统外部参与的者一个人或物 ，它以某种方式参与了系统的执行过程。
用列例 动：作待组开成发。系统的一个独立功用能例，由一系
用例间的关系：泛化、包含和扩展关系
简单大学用例图
学生
输入分数 注册讨论班 分发成绩单
用例图的组成
成绩管理员
参与者(actor)； 用例； 系统边界； 参与者与用例的
ATM维护人员 维护系统
后台服务器 周期性操作
ATM系统的参与者与角色之间的通讯关联
•参与者确定用例
查询
•参与者与用例对应
银行客户
存、取款
后台服务器
转帐
操作员
维护系统
周期性任务
系统时钟
3) 关于边界的选择
定义系统的边界是为了识别出什么在系统之内, 什么在系统之外,进而识别出什么是系统的职责。
系统需要的I/O是什么信息？信息流怎样流动
(也可能与当前角色无关)？
18
例：ATM系统的用例
参与者：银行客户 用 例：银行客户使用自动提款机来进行银行
帐户的查询、提款和转帐交易
银行客户
查询 取款 存款 转帐
例：ATM系统，有哪些参与者和用例？
用例
银行客户 维护人员 后台服务器
银行客户 查询 存款、取款 转账
<<extend>> <<extend>> 关系。
呼叫等待
呼叫转移
管理变更。
扩展关系是通过在关联关系上加入<<extend>>标记
来表示。扩展用例指向基本用例(被扩展用例)。 语义:用例1在某些特定情况下会用到用例2，用例2
的事件流将被插入到用例1的事件流中。 基本用例能独立存在,不依赖于它的扩展用例。 扩展用例可以不执行。
自动发生?
12
特殊的参与者：系统时钟
有时需要在系统内部定时的执行一些操作，如检测系统 资源使用情况、定期生成统计报表等，但这些操作并不 是由外部的人或系统触发的，这样可以抽象出一个系统 时钟或定时器参与者，利用该参与者来触发这一类定时 操作。
触发
系统时钟
周期性任务
从逻辑上，这一参与者应该被理解成是系统外部的， 由它来触发系统所提供的用例对话。
2
<<extend>>
<<extend>>
<<extend>>
<<extend>>
3 <<extend>>
<<extend>>
4 <<extend>>
<<extend>>
<<extend>>
标出下面用例图上的关系?
Login
<<include>> 创建新账户 删除账户
修改账户
登记借书 登记还书
<<include>> 验证读者
26
用例之间的关系：
<<include>>
用例1
用例2
(2) 包含(include) 基本用例
包含用例
银行客户
查询 取款 转帐
<<include>> <<include>> 卡片验证
<<include>>
许多用例的公共部 分移到一个单独的 被包含用例中。 公共部分需求变化 时,只改变被包含 用例的需求。
用例描述：登记借书
2.2 备选流程 (1) 读者没有注册 在主流程中，如果系统没有读者的注册信息， 系统将显示错误信息，用例结束。 (2) 所借图书不存在 在主流程中，如果所借图书已被借出或者系 统中无该图书，系统将显示错误信息，用例结束。
3 前提条件：用例开始前，图书管理员必须在系统登录 成功。
用例方法的思想
从用户的角度来看，他们并不想了解
系统的内部结构和设计，他们所关心的是
系统所能提供的服务，也就是被开发出来
的系统将是如何被使用的。
系统外部 并与该系 统发生交 互的人或 其他系统
通讯关联 参与者
用例
系统基本事件流， 代表用户期望系统 提供的基本功能
问:一个自动饮料售货机的功能是什么?
买票
采购员
采购物料
个人购买
用例2
团体购买
采购钢材 采购办公用品
当多个用例共同拥有一种类似的结构和行为的时 候，可将它们的共性抽象成为父用例，其他的用 例作为泛化关系中的子用例。
子用例继承了父用例所有的结构、行为和关系。
例: 标出下面用例图上的关系?
身份验证
付费
密码 验证
智能卡 验证
现金 支付
信用卡 支付
<<extend>>
查询
打印收据
存款
打印收据
<<include>>
35
例: 确定下面用例模型中的几种关系
通信关联
注册员
注册 进大学
学生
《extend》
在大学中 注册国际学生
《include》 注册
讨论班
泛化
在大学生中 注册家庭成员
国际学生
37
用例= 椭圆 + 名字？ —— NO！
用例模型
参与者 用例
Withdraw Use Case::Main flow 1.顾客插入银行卡 2.输入密码 3.输入提款金额 4.退卡 5.吐钞 6.选择是否打印收据:打印
扩展点
Extending Use Case
Print Receipt Use Case
1. 进纸 2. 打印 3. 吐纸