软件工程用例模型

顾客
结账
收款员
现金结账
银行卡结账
面向对象方法引论—用例模型
信息工程学院
例4：识别用例关系

某电话公司决定开发一个管理所有客户信息的交互式 网络系统。系统功能如下：



浏览客户信息：任何使用Internet的网络用户都可以浏览电 话公司所有的客户信息（包括姓名、住址、电话号码等）。 登录：电话公司授予每个客户一个帐号。拥有授权帐号的客 户可以登录系统。 修改个人信息：客户登录系统后，可以对个人信息进行修改。 删除客户信息：只有公司的管理人员才可以删除不再接受公 司服务的客户的信息。
信息工程学院
扩展关系 VS 包含关系

在扩展关系中，基用例不必知道扩展用例 的任何细节，事实上基用例没有扩展也是 完整的，只有特定的条件发生了，扩展用 例的行为才被执行。 而包含关系则不同，没有被包含的用例， 包含用例则不完整。

面向对象方法引论—用例模型
信息工程学院
泛化关系（generalization）
面向对象方法引论—用例模型
信息工程学院
面向对象方法引论—用例模型
用例模型
用例模型 简介
用例建模 技术
用例建模技术
识别参与者 识别用例 识别用例间的关系
用例阐述
练习
面向对象方法引论—用例模型
信息工程学院
识别参与者时需要思考的问题






谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴 趣 时间、气温等内部外部条件
面向对象方法引论—用例模型
信息工程学院
要点：用例的粒度(1)

把步骤当用例
会员
输入用户名
<<include>>
会员
登录
验证用户名和密码

把系统活动当用例
查询订单
<<include>> 建立数据库连接 <<include>>
执行SQL语句
面向对象方法引论—用例模型
信息工程学院
要点：用例的粒度(2)
保存注册信息
来自百度文库
面向对象方法引论—用例模型
信息工程学院
扩展关系（extend）


扩展用例是在原用例的基础上增加新的步骤序 列形成的。 原用例被称为基用例（base use case）。扩 展只能发生在基用例的序列中的某个具体制定 点上，这个点叫做扩展点（extension points）。
面向对象方法引论—用例模型
<<extend>>
面向对象方法引论—用例模型
信息工程学院
使用（Include）

即在一个用例中重用另一个用例中的步骤。
<<include>>
下订单 检索客户信息
面向对象方法引论—用例模型
信息工程学院
包含关系的误用！
<<include>> <<include>> 验证注册信息充分 <<include>> 潜在会员 注册 <<include>> 生成用户名和密码 填写注册信息
面向对象方法引论—用例模型
信息工程学院
要点：用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客 显示今日航班
用户观点
系统观点
面向对象方法引论—用例模型
信息工程学院
要点：用例的命名

执行者视角：

（状语）动词+（定语+ ）宾语
面向对象方法引论—用例模型
信息工程学院
要点：用例的粒度(1)

最常犯错误：粒度过细，陷入功能分解。过细 的粒度，一般都会导致技术语言的描述，而不 再是业务语言。
删除客户信息
管理员
授权客户
修改个人信息
电话公司客户管理系统用例图
面向对象方法引论—用例模型
信息工程学院
用例的描述

三种常用形式

摘要

简介的一段式概要，通常用于主成功场景 非正式的段落格式。用几个段落覆盖非正式场景 详细编写所有步骤及各种变化，同时具有补充部分，如前 置条件和成功保障。

非正式


面向对象方法引论—用例模型
信息工程学院
要点：有意义的目标
设定查询条件
会员 选择零件
会员
检索零件
面向对象方法引论—用例模型
信息工程学院
要点：结果值由系统生成
会员
检索零件
系统需要处理的，由系统生成
面向对象方法引论—用例模型
信息工程学院
要点：业务语言而非技术语言

用户词汇，而不是技术词汇

如：发票，商品，洗衣机 而不是：记录，字段，COM，C++等
信息工程学院
面向对象方法引论—用例模型
识别用例的注意事项

注意事项：





可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 命名规则 粒度大小
面向对象方法引论—用例模型
信息工程学院
要点：用例止于系统边界
描述交互，而不是内在的系统活动
面向对象方法引论—用例模型
信息工程学院

详述形式的用例模板内容
用例的不同部分 用例名称 范围 级别 主要参与者 涉众及其关注点 前置条件 成功保证 基本流程 分支流程 特殊需求 技术和数据变元表 发生频率 杂项 注释 以动词开始 要设计的系统 “用户目标”或是“子功能” 调用系统，使之交付服务 关注该用例的人及其需要 值得告知读者的，开始前必须为真的条件 值得告知读者的，成功完成必须满足的条件 典型的、无条件的、理想方式的成功场景 成功或失败的替代场景 相关的非功能性需求 不同的I/O方法和数据格式 影响对实现的调查、测试和时间安排 例如未解决问题
信息工程学院
面向对象方法引论—用例模型
用例图的应用

用例图是从用户的角度来描述对软件产 品的需求，分析产品的功能和外部可见 行为。

借助用例图，用户可以参与前期的系统 分析与设计。
面向对象方法引论—用例模型
信息工程学院
用例图对开发的意义
需求 分析和设计 实现 测试
Use Cases 把所有这些过程绑到一起
面向对象方法引论—用例模型
信息工程学院

非正式形式的样例项目用例
用例UC2：藏书管理 对个人拥有图书信息的管理。 用例UC2.1：添加藏书 基本流程： 1.藏书者登记新购买图书的信息，包括书名、作者、译者、出版社、购买时间（系统自动给出录 入时间）、价格、对图书的推荐信息、喜爱程度（默认情况下为3星，最高等级为5级，最低等级 为1级），数量（默认为1本，极个别情况会出现多本重复书籍）、归类（方便管理，可自己设定 归类名称）。 2.系统进行输入信息的有效性检查 3.系统根据图书名称进行重复图书检查 4.存储图书信息，并提示存储成功。 5.系统重新显示初始录入界面，用户可以进行下一本图书的录入过程。 分支流程： 1.a、如果藏书者录入信息有误 1、系统提示藏书者此信息 2、返回添加藏书界面，界面保持原来填写数据 3.a、如果图书名称发生重复，系统将提示此信息，并给出相应图书列表，用户可以查阅图书的 详细信息，同时要求用户对此情况进行处理。 1、 如果确认图书录入重复，则系统放弃对当前图书信息的存储 2、 如果只是同名不同书，则用户确认此情况后，系统对当前录入的图书信息进行保存。
参与者（Actor） 关系（Relationship） 系统（System）



一个用例是可以被行为 者感受到的、系统的一 use case 个完整的功能。 参与者是指在系统之 外，透过系统边界与系 Actor 统交互的任何事物，代 表外部实体。可能是人、 用例之间的关系有：扩 另外一个系统、时间的 展关系、使用关系和泛 流逝等。 化关系。 系统是提供用例的黑盒 子。其边界用矩形框表 示，用例图中也可不画 系统边界。

和类一样，泛化是指一个用例继承了另一 个用例，在用例继承中，子用例可以从父 用例继承行为和含义，还可以增加自己的 行为。
识别用户
子用例可以出现在父用例 出现的任何位置
验证口令 扫描指纹
面向对象方法引论—用例模型
信息工程学院
例3：用例之间的关系
扫描商品信息 累计消费积分
<<include>>
<<extend>>
例2：识别用例

Email服务器，A在北京发邮件给上海的B， 系统提醒B你有“新邮件”，B收邮件。
面向对象方法引论—用例模型
信息工程学院
时间
邮件服务器用例图
面向对象方法引论—用例模型
信息工程学院
识别用例间的关系

用例之间的关系有三种：扩展关系、使用关系 和泛化关系。
<<include>>
Include Extend Generalization
面向对象方法引论—用例模型
信息工程学院

详述形式的样例项目用例
用例 UC2.1：添加藏书 范围：应用 级别：用户目标 主要参与者：藏书者、资料管理员 涉众及其关注点： 藏书者：录入信息时，希望能够简洁快捷 前置条件：已经确认使用身份 成功保证：系统增加一条新录入藏书的信息 基本流程： 1、 登记新购买图书的信息，包括书名、作者、译者、出版社、购买时间（系统自动给出录 入时间）、价格、对图书的推荐信息、喜爱程度（默认情况下为 3 星，最高等级为 5 级，最 低等级为 1 级），数量（默认为 1 本，极个别情况会出现多本重复书籍）、归类（方便管理， 可自己设定归类名称）。 2、 系统进行输入信息的有效性检查 3、 系统根据图书名称进行重复图书检查 4、 存储图书信息，并提示存储成功。 5、 系统重新显示初始录入界面，用户可以进行下一本图书的录入过程。

“四轮马车”



C(Create) R(Read) U(Update) D(Delete) 所有业务最终对会成为 CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关 系数据库的建模：

增加用户
修改用户
管理员

“系统就是数据的增删改 查” 关心数据的存储和维护， 反而忽略了用户的目的
【问题】在需求分析阶段，采用用例图描述系统功能需 求，如下图所示，请指出图中的A、B、C和D分别是 哪个用例？
面向对象方法引论—用例模型
信息工程学院
A
网络客户
B
<<extend>>
C
管理员
授权客户
D
电话公司客户管理系统用例图
面向对象方法引论—用例模型
信息工程学院
浏览客户信息
网络客户
登录系统
<<extend>>
信息工程学院
面向对象方法引论—用例模型
例1：识别参与者

寻呼台系统：用户如果预定了天气预报，系 统每天定时给他发天气消息；如果当天气温 高于35度，还要提醒用户注意防暑；
在这个叙述里，谁是寻呼台系统的Actor？
面向对象方法引论—用例模型
信息工程学院
预定天气预报
用户
发送天气预报
时间
提醒防暑
温度
寻呼台系统用例图
详述


用例描述是文本形式的。
信息工程学院
面向对象方法引论—用例模型

对用例摘要式描述
登录：设定使用权限。用户提供用户名和密码，系统根据注册信息进行验证，通过 后根据用户权限显示主界面。 藏书管理：对个人拥有图书信息的管理。 添加：登记新购买图书的信息，包括书名、作者、译者、出版社、购买时间（系统 自动给出录入时间）、价格、对图书的推荐信息、喜爱程度（默认情况下为3星，最 高等级为5级，最低等级为1级），数量（默认为1本，极个别情况会出现多本重复书 籍）、归类（方便管理，可自己设定归类名称）。系统根据图书名称进行重复图书 检查之后，将图书信息进行存储，并提示存储成功。系统重新显示初始录入界面， 用户可以进行下一本图书的录入过程。 查询：根据指定条件进行图书信息的查询，条件包括书名、作者、购买时间范围、 喜爱程度、公开程度（是否进行晾晒）。 修改：图书资料的内容有可能会出现偏差，通过信息修改功能改正偏差 还书：将拣来的图书进行归还。从晒书场上捡来的图书到期后，拣书者应主动向藏 书拥有者归还图书。系统在收到捡书者的归还请求后，自动向藏书拥有者发送提示 信息。藏书拥有者在确定拿到图书后，通过系统进行确认彻底改变图书的状态（变 为被晾晒图书，或收回私人藏书室） 图书推荐：老师们可以推荐自己喜爱的图书，得到的推荐列表可以作为购买图书的 依据。
面向对象方法引论—用例模型
信息工程学院
参与者的泛化

参与者之间也可以象类一样存在泛化或者依 赖关系。
用户 登录系统
选课
学生
教师
安排教学计划
面向对象方法引论—用例模型
信息工程学院
识别用例时需要思考的问题



每个参与者的任务是什么 由参与者将要创建、存储、改变、删除或读取系统中 的信息吗 什么用例会创建、存储、改变、删除、或读取这个信 息 参与者需要通知系统外部的变化吗 需要通知参与者系统中正在发生的事情吗 什么用例将支持和维护系统 所有的功能需求都能被用例执行吗
查询用户
删除用户
面向对象方法引论—用例模型
信息工程学院
要点：用例的粒度(2)

如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可

不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示
管理员
管理用户
面向对象方法引论—用例模型
信息工程学院
面向对象方法引论—用例模型
用例模型
用例模型 简介
用例建模 技术
用例模型 (use case modul)
在UML中，一个用例模型由若干个用例图(use case diagram)描述。 用例图是用于显示一组用例、参与者以及它 们之间关系的图。
面向对象方法引论—用例模型
信息工程学院
用例图的组成

用例（Use Case）