6. 用例与用例之间的关系
(1) 泛化关系
定义 : 一个用例可以被列举为一个或多个子用例,父用例和子用例之间是泛化关系; 类似于类中的继承关系, 子用例是父用例的特殊形式, 子用例从父用例中继承行为和属性, 还可以添加行为或覆盖, 改变已继承的行为.
泛化关系表示 : 用例之间的泛化用带空心的箭头表示, 箭头方向指向父用例, 下图中系统管理员与查询用户是关联关系, 查询用户是父用例, 查询经理 查询员工是子用例;
(2) 包含关系
用例之间的包含关系 : 一个用例的行为包含了另一个用例.基础用例可以看到包含用例, 并依赖与包含用例的执行结果, 但是二者不能访问对方的属性.
包含关系表示 : UML中包含关系表示为虚线箭头, 并且在虚线箭头上有<<include>>字样, 箭头指向被包含的用例.
用例包含使用场景 :
a. 公用用例 : 为了复用用例, 当多个用例有重复的功能, 可以将重复的功能分解到另一个用例中, 将这个分解出来的用例与原来的多个用例建立包含关系.
b. 分解用例 : 为了简化用例, 当一个用例包含的功能太多的时候, 需要将用例分解成一个个子用例, 用例之间建立包含关系.
例子 : 管理员 修改用户, 删除用户 都要查询用户, 如果每次都编写事件序列, 那么用例会很复杂, 可以使用包含关系使 修改用户 删除用户用例 包含 查询用户;
(3) 扩展关系
定义 : 一个用例可以被定义为基础用例的增量扩展, 称作扩展关系.
作用 : 扩展关系可以把新行为插入到已有的用例的方法中.
扩展点 : 基础用例提供了一组扩展点,不必了解扩展用例, 这些扩展点中可以添加新的行为, 扩展用例提供了一组插入片段, 这些片段可以插入到基础用例的扩展点中;
扩展关系表示 : 虚线箭头指向基础用例, 箭头上加上<<extend>>;
基础用例与扩展用例关系 : 基础用例没有扩展用例也是完整的, 这一点与包含用例不同, 一个用例可以由多个扩展点, 每个扩展点可以出现多次.
扩展用例执行条件 : 一般情况下基础用例执行, 不会涉及到扩展用例行为, 如果特定条件发生, 扩展用例才会执行, 扩展关系为处理异常或构建灵活系统框架提供一种有效方法,发生的特定条件就是扩展点.
案例介绍 : 学生可以 查询图书, 借阅图书, 归还图书.
引入扩展关系 : 上面的用例图模型已经建好, 后来加上了如果借阅超期, 就要缴纳罚金, 更改用例图中的归还图书, 会使用例变得复杂, 因此可以在归还图书中简历扩展点, 在 图书超期 的特定条件下 , 将执行缴纳罚金 扩展用例;
四. 用例建模技术
1. 对语境进行建模
内部事物与外部事物 : 一个系统中, 会有一些事物存在其内部, 一些事物存在其外部.
语境定义 : 存在于系统内部的事物的任务时完成系统外部事物所期望的行为, 内部事物与外部事物存在交互,系统外部事物与内部事物构成了系统的语境, 语境又是系统的环境.
建模重心 : 用例视图是对系统的语境进行建模的,强调的是系统的外部事物, 即外部参与者;
对语境建模注意的方法 :
a. 外部参与者分类 :
从系统得到帮助以完成任务的组;
执行系统功能时所必须的组;
与外部硬件或其他软件系统进行交互的组;
为了管理维护系统而执行某些辅助功能的组.
b. 层次 : 将参与者组织成泛化/特殊化的结构层次;
c. 提供构造性 : 在需要的地方, 为每个参与者提供构造方法;
d. 通信路径 : 将参与者放到用例图中, 要说明参与者与用例之间的通信路径;
2. 对需求建模
需求 : 根据用户对产品功能的期望, 提出产品外部功能的描述;
需求分析 : 获取系统需求, 归纳系统索要实现的功能, 考虑系统做什么, 不去考虑怎么做;
对需求建模方法 :
a. 语境建立 :识别参与者, 建立系统语境;
b. 系统行为 : 考虑每个参与者期望的行为或需要系统提供的行为;
c. 命名原则 : 将公共行为命名为用例;
d. 包含扩展用例 : 确定供其他用例使用的用例和扩展其他用例的用例;
e. 建模对象 : 在用例图中对 用例 参与者 和 它们之间的关系建模;
f. 需求描述 : 注释用例图要描述非功能需求;
3. 用例粒度
学生去图书馆借书, 首先登陆系统, 输入账号, 输入密码, 提交. 但上面的几部每个都可以算作一个用例, 但是综合起来也可以将三部算作一个用例.
针对需求分析人员来说 : 用例粒度的粗细可以根据实际情况分析;
针对开发人员来说 : 用例的粒度越细越好;
