用例图

一. 用例视图概述

 

用例视图表述哪些事物 :谁是相关用户,用户希望从系统获得的服务,用户需要为系统提供的服务.

用例视图的作用 : 使用户容易理解 其中元素的用途 , 使码农更容易实现这些元素.

软件产品外部特性 :软件功能的合理性,使用方便程度,UI界面;

用例视图角度 : 用例视图是从用户角度来描述软件产品的需求, 可以准确的描述软件产品的外部特性.

用例视图元素 :参与者,用例, 参与者 用例之间的关系(泛化, 包含, 扩展); 用例图还可以包含注解, 约束, 包.

二. 参与者

1. 参与者概念

定义 : 参与者是系统外部的实体, 参与了系统用例执行过程. 

参与者与用例交互方式 : 参与者通过交换信息与用例发生交互.

参与者种类 : 

a. 用户 : 真实的人, 这类参与者命名按照业务命名.

b. 其它系统 : 程序边界之外的系统, 例如 银行支付系统也是电商网站的参与者.

c. 进程 : 一些可以运行的进程也可以做参与者, 例如到某个时间触发某时间, 时间就是参与者.

2. 确定参与者

(1) 如何识别参与者

a. 系统使用者 : 使用系统的用户或者系统是参与者;

b. 交互中角色 : 在交互中参与者扮演的角色;

c. 系统安装者 : 安装这个系统的人也可能是参与者;

d. 系统启动者 : 开启关闭系统的人可能是参与者;

e. 系统维护者 : 维护这个系统的人可能是参与者;

f. 交互的系统 : 与该系统交互的系统可能是参与者;

g. 信息获取者 : 从系统获取信息的人可能是参与者;

h. 信息提供者 : 为系统提供信息的人可能是参与者;

i. 定时执行者 : 在固定时间执行某个用例.

(2) 参与者注意事项

a. 系统之外 : 参与者是系统外部的元素, 是不可控制的;

b. 系统边界 : 参与者同系统交互, 可以定义系统的边界;

c. 注重业务 : 参与者是人活着事务与系统发生交互时所扮演的角色, 而不是人或者事务, 例如 电商卖家登陆后台就是卖家, 登陆前台就是卖家, 注重业务而不是注重人.

d. 人多角色 : 一个人或事务可能扮演多个角色;

e. 业务命名 : 参与者命名是按照业务来命名的;

f. 业务描述 : 每个参与者必须有简短的描述, 从业务角度描述参与者是什么;

g. 属性方法 : 参与者也可以有属性和方法, 不常用;

3. 参与者之间关系

参与者之间有泛化关系, 就是接口与实现类之间的关系. 例如在OA系统中, 项目经理 客户经理 都是员工, 项目经理与员工之间的关系就是泛化关系.

三. 用例

1. 用例概述

用例概念 : 用例是对一个系统或一个应用的一种单一的使用方式所做的描述, 是关于单个活动者在与系统对话中所执行的处理行为的陈述序列(用例不是单一的动作, 是一系列的动作).

用例描述的事物 : 用例表示参与者使用系统完成某个事件时事情发生的序列, 用例是系统的使用过程, 展示和体现了其描述的过程中的需求情况.

2. 用例图表示

用例用椭圆表示, 名称可以写在椭圆的内部或者下方. 用例的名字包括简单名(simple) 和 路径名(path name), 简单明就是只写用例名, 路径名就是在用例名前加上其所属的包名.

3. 识别用例

从分析系统参与者开始, 考虑参与者怎样使用系统, 这样既可以分析用例, 又可以找出一个新的参与者, 对完善系统建模很有帮助.

用例建模就是这样迭代和逐步精华的过程, 这是属于系统分析师的职责.

识别用例的方法 : 

a. 根据参与者 : 特定参与者希望系统提供的功能;

b. 根据系统行为 : 系统对数据库进行操作, 是哪个参与者通过什么用例触发;

c. 状态改变 : 系统状态改变的时候,是否通知参与者;

d. 外部事件 : 是否存在影响系统的外部事件;

e. 通知者 : 哪个参与者通知系统这些事件;

4. 用例与事件流

事件流产生原因 : 用于分析出息系统的需求分析阶段, 在这个阶段应该避免考虑系统实现的细节问题, 因此我们将用例的细节写在事件流文件中,事件流是用来描述用例的详细执行过程的;

事件流概念 : 事件流用来说明一个用例的具体的行为, 何时开始, 何时结束, 与参与者有什么交互.

事件流分类 :基本流,可选流; 基本流就是主事件流, 一个用例的正规流程没有任何意外就是主事件流, 如果中间出了一场, 那么就是可选事件流, 又叫异常事件流.

举例 : 用户登录

主事件流 : 参与者输入账号密码, 登陆开始,服务器判断密码是否正确, 密码正确, 进入系统;

异常事件流1 : 密码错误, 重新登陆;

异常事件流2 : 密码提交前用户清除密码, 重新填写.

5. 参与者与用例之间的关系

参与者与用例之间的关系是关联关系, 使用带箭头的实线表示关联关系, 例如 : OA系统客户登陆, 用户签到, 写文件, 审批文件.

6. 用例与用例之间的关系

(1) 泛化关系

定义 : 一个用例可以被列举为一个或多个子用例,父用例和子用例之间是泛化关系; 类似于类中的继承关系, 子用例是父用例的特殊形式, 子用例从父用例中继承行为和属性, 还可以添加行为或覆盖, 改变已继承的行为.

泛化关系表示 : 用例之间的泛化用带空心的箭头表示, 箭头方向指向父用例, 下图中系统管理员与查询用户是关联关系, 查询用户是父用例, 查询经理 查询员工是子用例;

(2) 包含关系

用例之间的包含关系 : 一个用例的行为包含了另一个用例.基础用例可以看到包含用例, 并依赖与包含用例的执行结果, 但是二者不能访问对方的属性.

包含关系表示 : UML中包含关系表示为虚线箭头, 并且在虚线箭头上有<<include>>字样, 箭头指向被包含的用例.

用例包含使用场景 : 

a. 公用用例 : 为了复用用例, 当多个用例有重复的功能, 可以将重复的功能分解到另一个用例中, 将这个分解出来的用例与原来的多个用例建立包含关系.

b. 分解用例 : 为了简化用例, 当一个用例包含的功能太多的时候, 需要将用例分解成一个个子用例, 用例之间建立包含关系.

例子 : 管理员 修改用户, 删除用户 都要查询用户, 如果每次都编写事件序列, 那么用例会很复杂, 可以使用包含关系使 修改用户 删除用户用例 包含 查询用户;

(3) 扩展关系

定义 : 一个用例可以被定义为基础用例的增量扩展, 称作扩展关系.

作用 : 扩展关系可以把新行为插入到已有的用例的方法中.

扩展点 : 基础用例提供了一组扩展点,不必了解扩展用例, 这些扩展点中可以添加新的行为, 扩展用例提供了一组插入片段, 这些片段可以插入到基础用例的扩展点中;

扩展关系表示 : 虚线箭头指向基础用例, 箭头上加上<<extend>>;

基础用例与扩展用例关系 : 基础用例没有扩展用例也是完整的, 这一点与包含用例不同, 一个用例可以由多个扩展点, 每个扩展点可以出现多次.

扩展用例执行条件 : 一般情况下基础用例执行, 不会涉及到扩展用例行为, 如果特定条件发生, 扩展用例才会执行, 扩展关系为处理异常或构建灵活系统框架提供一种有效方法,发生的特定条件就是扩展点.

案例介绍 : 学生可以 查询图书, 借阅图书, 归还图书. 

引入扩展关系 : 上面的用例图模型已经建好, 后来加上了如果借阅超期, 就要缴纳罚金, 更改用例图中的归还图书, 会使用例变得复杂, 因此可以在归还图书中简历扩展点, 在 图书超期 的特定条件下 , 将执行缴纳罚金 扩展用例;

四. 用例建模技术

1. 对语境进行建模

内部事物与外部事物 : 一个系统中, 会有一些事物存在其内部, 一些事物存在其外部. 

语境定义 : 存在于系统内部的事物的任务时完成系统外部事物所期望的行为, 内部事物与外部事物存在交互,系统外部事物与内部事物构成了系统的语境, 语境又是系统的环境. 

建模重心 : 用例视图是对系统的语境进行建模的,强调的是系统的外部事物, 即外部参与者;

对语境建模注意的方法 : 

a. 外部参与者分类 : 

从系统得到帮助以完成任务的组; 

执行系统功能时所必须的组; 

与外部硬件或其他软件系统进行交互的组; 

为了管理维护系统而执行某些辅助功能的组.

b. 层次 : 将参与者组织成泛化/特殊化的结构层次;

c. 提供构造性 : 在需要的地方, 为每个参与者提供构造方法;

d. 通信路径 : 将参与者放到用例图中, 要说明参与者与用例之间的通信路径;

2. 对需求建模

需求 : 根据用户对产品功能的期望, 提出产品外部功能的描述;

需求分析 : 获取系统需求, 归纳系统索要实现的功能, 考虑系统做什么, 不去考虑怎么做;

对需求建模方法 : 

a. 语境建立 :识别参与者, 建立系统语境;

b. 系统行为 : 考虑每个参与者期望的行为或需要系统提供的行为;

c. 命名原则 : 将公共行为命名为用例;

d. 包含扩展用例 : 确定供其他用例使用的用例和扩展其他用例的用例;

e. 建模对象 : 在用例图中对 用例 参与者 和 它们之间的关系建模;

f. 需求描述 : 注释用例图要描述非功能需求;

3. 用例粒度

学生去图书馆借书, 首先登陆系统, 输入账号, 输入密码, 提交. 但上面的几部每个都可以算作一个用例, 但是综合起来也可以将三部算作一个用例.

针对需求分析人员来说 : 用例粒度的粗细可以根据实际情况分析;

针对开发人员来说 : 用例的粒度越细越好;

五. 图书管理系统用例视图建模实战

1. 确定系统涉及的内容

图书管理系统是对书籍的借阅及读者信息进行统一管理的系统, 由以下模块组成 : 

读者 : 借书, 还书, 预定书籍;

图书管理员 : 书籍借出处理, 书籍归还处理, 预定信息处理;

系统管理员 : 系统维护, 书目的 增删改, 书籍 增删改, 读者账户 增删改, 书籍信息 读者信息的查询;

2. 分析系统参与者

确定参与者首先分析系统涉及的问题领域 和 系统运行的主要任务 : 系统使用者, 系统维护者;

分析过程 : 

a. 首先该系统需要读者参与, 读者登陆系统 借书 还书 预定书籍;

b. 对应读者的请求, 需要有图书管理员处理这些信息;

c. 系统的维护也是相当重要, 需要对系统的 书 用户 等方面进行增删查改等操作;

系统的参与者有三类 : 读者, 图书管理员, 系统维护者;

3. 分析系统用例

用例是系统参与者与系统交互过程中需要完成的事务, 分析用例最好的方法是从分析参与者开始.

(1) 读者相关的用例

a. 登陆系统

b. 查询自己的借阅信息;

c. 查询书籍信息;

d. 预定书籍;

e. 借阅书籍;

f. 归还书籍;

(2) 图书管理员

a. 处理书籍借阅

b. 处理书籍归还

c. 删除预订信息

(3) 系统管理员

a. 查询借阅者信息

b. 查询书籍信息

c. 书目 增删 更新

d. 书籍 增删

e. 借阅者账户 增删改

4. UML 用例图

借阅者用例图 : 

图书管理员用例图 : 

系统管理员用例图 :