2 设计用例图的案例

系统开发出来后，使用系统主要功能的是谁？ 谁需要借助系统来完成日常工作？ 系统需要从哪些人或其他系统中获取数据？ 系统会为哪些人或其他系统提供数据？ 系统会与哪些其他系统交互？ 系统是由谁来维护和管理的，以保证系统处于工作状 态？ 系统控制的硬件设备有哪些？ 谁对本系统产生的结果感兴趣？

同一个系统由于用例的粒度不同，不同人会产生不同 的用例模型。
用例图—用例
用例的识别


参与者希望系统提供什么功能？
参与者是否会读取、创建、修改、删除、存储系统的 某种信息？如果是，参与者又是如何完成这些操作的？

参与者是否会将外部的某些事件通知给系统？ 系统中发生的事件是否通知参与者？ 是否存在影响系统的外部事件？
使用Rose画图并不画系统边界，采用 Visio画图，用方框表示系统边界。 系统边界不一样，它的参与者就会发 生很大变化。搞清系统边界才能更好 地确定系统的参与者和用例。

系统 参与者 用例
用例图—用例
用例和参与者之间也有关系，这种关系属于关联关
系，是双向的一对一关系，表明了哪个参与者与用 例通信。

总结

根据系统陈述建立模型过程中，很重要的一点 是要分析陈述中哪些是无用的信息，哪些是有用 的信息，哪些是可以合并的信息。
建立用例模型

练习：银行账户管理系统需求陈述如下：
一个客户可以在多个银行中开设账户，一个客户也
可在同一银行中开设多个不同的账户。客户可以通 过银行职员进行开户、存款、取款、转账、注销账 户等活动。其中转账指客户将自己的某个账户上的 钱转入同一银行的不同账户（称为银行内转账）或 转入不同银行的账户（称为银行间转账）。系统管 理员负责系统的账户管理及业务报表的生成。
建立用例模型两种思路

1、找到每个Actor在系统中的功能，然后将所有 Actor的功能合并为一张用例图。 ——见案例1 2、将一个大系统划分为几个子系统，为每个子系 统分别建立用例图。 ——见案例2

建立用例模型案例1

详细用例建模过程举例：学生注册管理系统
识别参与者：

教师、学生、注册管理员、收费系统
确定用例：

与教师有关的用例

选择课程--选择所教的课程，并获得学生名册
wenku.baidu.com
登记成绩--在学期结束时，提交学生的课程成绩。

与学生有关的用例

注册课程--在学期开始进行选课注册，允许在一段时间内 更改或删除，课程目录系统提供当前学期的所有可选课程 列表
查看成绩单--学生可以查看以前学期的电子成绩单。
用例图

用例图源于Jacobson的OOSE方法，它通过用例来 捕获系统的需求，再结合参与者进行系统功能需求 的分析和设计。
用例图由参与者、用例、系统边界和关联组成。
用例和参与者之间的对应关系称为通信关联 箭头表示在这一 （Communication Association）。 关系中哪一方是 使用用例图来描述系统，主要弄清楚三方面内容: 对话的主动发起
8. 打印存折，用例结束 后臵条件：在账户库中增加一个新账户，得到一张新存折
作 业

教材230页第10题。
作 业

教材230页第10题。
仓库管理员通过放在仓库
中的终端把零件入库/出 库事务报告给订货系统， 系统接收到事务信息后应 该处理事务；
采购员需要使用订货系统
提供的产生报表功能，以 获取订货报表。

注意：
在用例图中，只能展示系统大的功能模块，对功能
的细节部分无法展示，如“每个学生可以选择不超 过4门课程，同时指定2门候选课程以备主选课程未 选上。每门课程最多不能超过10人，最少不能低于 3人，低于3人选课的课程将被取消”这样的细节可 以在用例图中为某个用例添加上“注释”。
建立用例模型案例2
确定用例：

学生信息管理的用例 班级信息管理的用例
成绩管理的用例
网上选课的用例 账号管理的用例

注意：《include》应用的两 种场合：

1、多个用例都用到某个同 样的功能，将这个功能抽取 出来，单独编写，供其他用 例调用。
好处：避免了重复编写相同 的功能。


2、当某个功能包含若干个子功能时，使用《include》展 示子功能。 需要注意的是要区别是使用《include》合适还是使用“泛 化”合适。


与注册管理员有关的用例

维护课程信息--在系统中增加、修改和删除课程信息；
维护学生信息--在系统中增加、修改和删除学生信息； 维护教师信息--在系统中增加、修改和删除教师信息。
关闭注册--删除少于3人的课程，并由付费系统通知学生缴费。

与安全性要求有关的用例

登录--使用此系统的人员需要进行登录，以验证其身份和权限。

者，箭头所指方 参与者——与系统交互的人或物。是向系统输入或系
统输出的对象。用一个小人图形表示。 是对话的被动接 受者。 用例——系统的一个功能。用椭圆表示。 用例和参与者之间的关系——用带箭头的线段来描述。
用例图—参与者

参与者（Actor）是指存在于系统外部并直接与系
统进行交互的实体。

注意寻找参与者时不要只考虑使用计算机的人！
用例图—参与者

参与者间的关系
用例图—系统边界

系统边界是指系统与系统之间的界限。
系统与环境之间存在边界，子系统与
其他子系统之间存在边界，子系统与 整体系统之间也存在边界。 用例图中的系统边界用来表示正在建 模系统的边界，边界内表示系统的组 成部分，边界外表示系统的外部。
软件工程导论
孙旭光
灾害信息工程系
功能模型

在面向对象方法学中，可以使用UML提供的用例 图进行需求分析和建立功能模型。
也把用用例图建立起来的系统模型称为用例模型。
使用用例模型代替传统的功能说明，能更好地获取
用户需求，它所回答的问题是“系统应该为每个用
户做什么”。
用例模型描述的是外部行为者所理解的系统功能。

详细用例建模过程举例：学生信息管理系统
识别参与者：

学生、教师、校领导、系统管理员
登录 登录 查询学生基本信息 找回密码登录 登录 录入学生基本信息 录入成绩 找回密码 找回密码 修改学生基本信息 创建新账号 修改成绩 查询课程信息 查看班级基本信息 删除学生基本信息 设臵账号 保存成绩 按课程编号查看 录入班级基本信息 找回密码 设臵账号基本信息 查询成绩 按课程名查看 修改班级基本信息 设臵账号权限 删除成绩 选择课程 删除班级基本信息 删除账号 删除已选课程 查看账号 维护课程信息
参与者是用户相对系统而言所扮演的角色。 每个参与者可以参与一个或多个用例，每个用例也
可以有一个或多个参与者。
参与者不仅可以由人承担，还可以是其他系统、硬
件设备，甚至是时钟。

参与者虽然可以代表人或事物，但参与者不是指人或 事物本身，而是表示人或事物当时所扮演的角色。
用例图—参与者
参与者的确定：

建立用例模型：银行账户管理系统需求陈述如下：
用例名称：开户 一个客户可以在多个银行中开设账户，一个客户也 参与者：银行职员（客户代理）、客户
前臵条件：一个合法的银行职员（客户代理）已登录到该系统 可在同一银行中开设多个不同的账户。客户可以通 事件流： 过银行职员进行开户、存款、取款、转账、注销账 1. 当选择开户功能时用例开始 2. 输入客户信息（姓名、地址、身份证号等） 户等活动。其中转账指客户将自己的某个账户上的 3. 从账户管理系统获取新的账号 钱转入同一银行的不同账户（称为银行内转账）或 4. 请客户输入密码 5. 请客户再次输入密码 转入不同银行的账户（称为银行间转账）。系统管 6. 如果两次密码不一致则回到第4步，否则继续 理员负责系统的账户管理及业务报表的生成。 7. 在账户库中添加新账户