需求用例建模方法

注意
在使用参与者为角色建模中是一种抽象， 不为具体的人、机构、系统建模。 输入分数 张助教 核对分数 分发成绩单 刘老师
图 3-6 对职位建模(不合理)
13
2) 确定用例 用例描述一个事件发生,产生动作步骤的集合。 以编制好的需求规格说明文档为基础
(1) 基于参与者的方法 对每个参与者,识别出他们发起或参加 的执行过程。 (2) 基于事件的方法

利用这些关系来调整、优化用例模型，抽取公共的 信息，便于复用和维护。
actor 1
客户
1) 参与者之间的关系
actor 2

上网登 记客户
电话登 记客户
参与者之间的泛化(Generalization)关系
普通用户
常规操作
常规操作
用户
管理员
管理操作
管理员
管理操作
系统维护员
配置操作
系统维护员
配置操作
ATM系统的改进用例图
查询
存、取款 银行客户 转帐 维护系统 维护人员 周期性任务 系统时钟 后台服务器
图 3-8 改进的ATM系统用例图
系统的启动用例

购买商品 登录 出纳员
几乎所有的 系统都包含 一个系统启 动用例。
退还商品
启动
顾客
管理用户 系统管理员
其他
管理员
图 3-9 POST系统部分用例图
3.2.1 什么是用例
问:一个自动饮料售货机的功能是什么? 答:通过自动饮料售货机购买一听饮料(买饮料)。
通信 参 与 者
顾客
收款员 供应商
买饮料
收款 提供饮料
用 例
图 3-3 自动饮料售货机的用例图
用例：站在用户角度定义软件系统的外部特征(1) 用例：是系统执行的动作集合规格说明 (2)
用例的特征：
例,包含关系的几种可能性
1 <<include>> <<include>> 2 <<include>> <<include>>
3 <<include>>
4 <<include>> <<include>>
×
<<include>>
<<include>>
图 3-15 包含关系的几种可能性
用例之间的关系：



特定的角色(particular actor)触发某些行为 行为序列(sequences of actions) 系统执行(system performs)提供的服务 可观测到的、有价值的结果(observable result of value)。
9
用例分析技术
3.2.2 基本用例图(use case diagram)的组成
需求分析 与建模
规格 说明
需求 验证
产出物 会议纪要 讨论纪要 分析模型 需求规格 说明书 审核通过的 规格说明书
图 3-1 需求分析阶段的活动
3.2 软件需求-用例建模技术
在结构化的软件需求 “系统做什么?”的问题中,增 加三个词“for each user”, 使问题变为“系统应该为每 个用户做什么? ”,系统对用
这个用例有什么问题?
17
3) 边界的选择
定义系统的边界是为了识别出什么在系统之内, 什么在系统之外,进而识别出什么是系统的职责。
•典型的系统边界包括:硬件设备或硬件/软件边界 一个组织中的部门或整个组织。 POST 商店 购买 商品 登录 出纳员 顾客 购买 商品 退还 商品 顾客
退还 商品
图 3- 10 以POST工作为系统边界
回顾:邮购的业务过程分析
客户 填写订 货表单 客户服务部 下订单 销售部门 处理订单
有库存 无库存
库存部门
财务部门
发送货物 接受货物
发送发 货单
接受发 货单
填写注 册表单
注册会员
订货
邮购公司业务活动图
发出 货款
下面要进行什么分析?
软件需求?
内容


回顾需求的活动 用例图和用例的描述
重点

图 3-12 参与者的泛化关系
2)
(1)
用例之间的关系
父用例
子用例
泛化(generalization )关系
采购物料
付费方式 支付 现金 支付 信用卡 买票 购买 个人票 购买 团体票
采购员
采购 钢材
采购办 公用品
图 3-13 用例的泛化关系


将它们的共性抽象成为父用例，其他的用例作为泛化 关系中的子用例。 子用例继承了父用例所有的结构、行为和关系。
户有什么价值。
用例的概念在1986年 由Ivar Jacobson正式 提出之后被广泛接受， 迅速发展，已成为OO、 UML、RUP的标准规 范和方法。

用例方法的思想：
从用户的角度看，他们所关心的是系统所能 提供的服务，用户使用系统完成不同的任务。 通讯关联 系统外部，并与 用例 该系统发生交互 参与者 的人或其他系统。 图 3-2 系统透视 系统基本 事件流。
邮购系统用例级别的业务活动问题描述






客户通过填写会员注册表单并将发送给公司经审批成为会员。 会员在一年内无活动,将会被删除。 会员的个人信息改变后,应通知公司。 会员填写销售表单并发送给公司,会员可以订购了。 客户服务助理也可以通过电话方式处理订单。 客户服务助理检查会员资格的有效性后可将订购信息输入 到系统。 库存握制员负责对库存量的监管及订货。 若订单有问题,会员电话联系服务助理,并由助理追查销售 订单。 会员可在30天内退还次品,并取回货款。 系统执行的每项任务都会记录相关员工的名字和ID。
11
确定参与者(actor)

特殊的参与者：系统时钟
利用该参与者触发系统的一类定时操作。如定时检测
系统、资源使用情况、定期生成统计报表等，这些操 作并不是由外部的人或系统触发的。 触发 系统时钟
周期性任务
图 3-5 特殊的参与者
从逻辑上，这一参与者应该被理解成是系统外部的，
由它来触发系统所提供的用例对话。
国际学生
图 3-19 用例模型中的几种关系
练习：举例说明用例的含包关系和扩展关系的区别。
29源自文库
3.2.4 用例的文字描述 用例 = 椭圆 + 名字？ —— NO！
用例模型
Name of the Use Case (用例的名字) Description (描述) Actor(s) (参与者) Flow of events (事件流) Basic flow (常规流) Event 1 (事件) Event 2 …… Alternate flow (备选流) Pre-conditions (前置条件) Post-conditions (后置条件) ……
用例之间的关系：
(2) 包含(include)
基用例
<<include>>
被包含用例
查询
银行客户
取款 转帐
<<include>> <<include>> 卡片验证 <<include>>
许多用例的公共 部分移到一个单 独的被包含用例中。
图 3-14 用例的包含关系


包含关系是：基用例指向被包含用例。 语义：基用例会用到被包含用例，被包含用例的 事件流被插入到基用例的事件流中。 基用例不能独立存在,必须依赖于被包含用例。 被包含用例一定要执行。
修改账户
登记还书
<<extend>> 查询读者 登记 <<extend>> 借书 查询读书
<<extend>> 参加考试 补考
图 3-18 有包含关系和扩展关系的用例图1
27
例:
订货 <<include>> <<include>>
提供客户数据
订货 <<extend>> 请求目录 <<extend>> 查询 打印收据 存款 打印收据 <<include>> 分开表示
用例图显示了系统的一组用例、用例的参与 者及二者之间关系的图。
用例图的组成
输入分数 成绩管理员 注册讨论班 学生 分发成绩单 注册员 图 3-4 简单大学用例图

参与者(actor) 用例 系统边界（隐藏） 参与者与用例的 通信关联
(communication association)
10
1) 参与者 (actor)
人与系统进行交互时能够担任的不同角色为 参与者(actor)。


参与者可以是人也可以是其他系统。 参与者是系统的真正用户,但二者并不存在一对 一的对应。 参与者访问系统是有级别的,可由系统功能而定。 系统的主要客户是谁? 系统从什么地方得到信息? 该系统与其他系统交互信息是什么? 在某一个预定时间，自动发生什么事情?
(1)寻找参与者和用例---建立初始的用例图
检查订单状态 处理订单 下订单 安排发货 处理退货
订单处理员
客户服务助理
更新会员记录
订货 接收货物 发送货物
参与者 用例
...
用例规约 术语表
3.2.5 如何建立用例模型
在业务需求陈述的基础上: (1)建立初始的用例图。 确定参与者 确定用例 建立参与者与用例的关联 (2)进行用例的文字描述 (3)细化用例 进一步标明用例间的包含、扩展、泛化关系 (4)对用例进行分组，用包图表示。
例1 邮购系统
# 识别出系统必须响应的外部事件； # 把事件与参与者和用例联系起来。
14
例：ATM系统的用例

参与者：银行客户 用 例：银行客户使用自动提款机来进行银行 帐户的查询、提款和转帐交易 查询
存款
银行客户 取款 转帐 维护系统 后台服务器 周期性操作 维护人员 还有哪些改进? 还有哪些用例?
图 3-7 ATM系统的用例图

例:用例之间的关系：扩展(extend)
<<extend>> 打电话 <<extend>> 呼叫等待 呼叫转移
常规流： 常规流： 常规流： 1 拨号 1 如果应答方正忙， 1 如果应答方 2 建立通话链路 用铃声提示应答方 无应答，进行 呼叫转移 3 通话 并保持拨号呼叫 4 挂机 实际上相当于第一个用例的“备选流”
扩展关系的几种可能性
1 <<extend>> <<extend>> 2 <<extend>> <<extend>>
3 <<extend>> <<extend>>
4 <<extend>> <<extend>>
<<extend>>
图 3-17 扩展关系的几种可能性
例,标出下面用例图上的关系?
启动系统 <<include>> 创建新账户 删除账户 <<include>> 登记借书 验证读者 <<include>>
(3) 扩展(extend)
基用例 (不变部分)
<<extend>>
扩展用例 (可变部分)
打电话
银行客户
<<extend>> <<extend>>
呼叫等待
呼叫转移
一个用例中有许多替代 物或选择时,使用扩展关 系,管理变更。
图 3-16 用例的扩展关系

扩展关系是：扩展用例指向基用例(被扩展用例)。 语义:基用例在某些特定情况下会用到扩展用例，扩 展用例的事件流将被插入到基用例的事件流中。 基用例能独立存在,不依赖于它的扩展用例。 扩展用例可以不执行。
什么是用例? 用例图包括哪些内容? 用例的文字描述的步骤?
4
3.1 需求(requirement)与需求的活动
需求就是要获得系统提供的所有服务,是“做什么”
软件需求包括五个层次：
业务需求
用户需求
功能和非功能需求 环境、约束的需求 接口的需求
5
需求分析阶段的活动 需求管理
需求 获取
图 3- 11 以商店工作为系统边界
18
3.2.3 用例图上的其他关系

在基本的用例图中，只需表述参与者和用例之间的 通讯关系。 此外，还可以描述：


参与者与参与者之间的泛化关系(generalization)。 用例和用例之间的泛化(generalization)关系， 包含(include)关系， 扩展(extend)关系。
第3章 软件需求的 用例建模方法
1
回顾:邮购的业务过程分析
邮购系统的业务过程陈述（工作流）：



公司的目标是为公司的所有注册会员提供高质量的邮购服务。 任何个人或公司只要完成注册表单并将其发送到客户服务部 门，成为会员。 会员可以通过填写订购表单并将其发送给客服部门进行订购。 客服部门验证会员资格，将订单转给销售部门。 库存有货，销售部门处理订单，并将发货单存给库存部门。 库存无货，销售部门向供应商发送购货单。 购买的货物到后，入库，库存部门将货物交给该会员，财务 部门将发票给会员。 财务部门收到供应商的物品及发票，验证合格后，将货款打 给供应商。
订货项目
查询
<<extend>>
打印收据
存款 <<include>> 既是扩展用例也是被包含用例
图 3-18 有包含关系和扩展关系的用例图2
28
例: 确定下面用例模型中的几种关系
通信关联 注册员 基用例 《include》 注册 注册 进大学 讨论班 《extend》 学生 在大学中注 册国际学生 泛化 在大学生中 注册家庭成员