提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档
文章目录
1、用例建模概念
1.1用例在需求管理过程中的作用
1.2用例模型的表示
- 文本描述
1.3 用例图的主要元素
参与者:
与系统交互的人或外部系统
与系统交互的硬件组件
关注的重点是所承担的“角色”
参与者的名要明确定义其角色
用例:
定义一个参与者要用到的系统功能
通过此刻为参与者提供有价值且可观测的结果
描述系统为实现参与者价值所开展的行为序列
对参与者与系统之间的交互活动进行建模
从特定的用户角度出发,是完整的,实现特定用户的事件流
关联:
用例图中用例与参与者之间的交互关系
用一条直线表示交互——关联
有箭头的关联指出是谁发起的交互
没有箭头则表明双方都可以放弃交互
场景:
场景是用例的实例
2、用例建模过程
2.1 构建用例模型的步骤
- 找到所有的参与者和用例
- 识别出参与者并做简单的描述
- 识别出用例并做简单的介绍
- 编写用例
- 给用例事件流程划分重要等级
- 按照重要程度排序详细描述事件流程
2.2 参与者
- 谁/什么使用系统?
- 谁/什么从系统中获取信息?
- 谁/什么向系统提供信息
- 公司的哪个部门会使用系统
- 谁/什么负责系统的维护
- 还有哪些其他的系统会使用系统
识别参与者——是谁与系统进行交互
参与者建模的检查项
- 是否找全所有的参与者?是否对系统环境中的所有的角色进行了描述和建模?
- 每个参与者是否至少与一个用例发生了交互?
- 是否可以为每一个角色找到至少两个实例?
- 不同参与者与系统的交互是否一致扮演的角色是否相似?如果有,则应该要合并这些参与者作为同一个角色
2.3 用例
寻找用例
- 描述系统为参与者提供的服务/参与者如何与系统交互
- 基本策略:把自己当作actor,与设想中的系统进行交互。
- 每个参与者的目标是什么?
- 为什么参与者要使用这个系统?
- 参与者是否需要对系统中数据进行创建,存储,更改,删除或者读取的操作?为什么?
- 参与者是否需要将外部事件或发生的改变告知系统?
- 参与者是否需要找到系统内部发生的事件或改变?
- 系统是否能够应对业务中所有的正确行为与操作?
用例的命名
- 表面参与者的目标或者作用
- 使用主动语态:用动词起始
- 设计一系列操作流程( to-do list)
用例建模过程中的检查项
- 用例建模是为了表示系统的行为。通过模型可以很容易理解系统进行的操作
- 应该识别出所有的用例,用来表达所有的需求
- 系统的任何一个特性都可以找到对应的用例
- 用例模型并不包括多余的行为;所有的用例可以追溯到系统的功能性需求作为验证
- 去掉所有的CRUD类的用例
2.4用例建模的过程
用例图——>用例提纲——>用例详细规约
2.5 总结:Use Case模型的建立步骤
- 找出系统外部的参与者和外部系统,确定系统的边界和范围;
- 确定每一个参与者所期望的系统行为;
- 把这些系统行为命名为Use Case;
- 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分;
- 编制每一个Use Case的脚本;
- 绘制Use Case图;
- 区分主事件流和异常情况的事件流,可以把表示异常情况的事件流作为单独的Use Case处理;
- 细化Use Case图,解决Use Case间的重复与冲突问题。
3、用例建模精讲
3.1设定系统边界
- 系统边界:一个系统所包含的所有系统c成分与系统以外各种事物的分界线
- 系统边界会对用例以及参与者的定义有所影响
3.2不要把用例定义成功能分解
如何避免功能性分解?
问题现象:
- 非常细小的用例
- 用例过多
- 没有实际价值的用例
- 通过底层操作进行命名
- “操作”+“对象”
- “功能”+“数据”
- 很难理解整体模型
修改思路:
- 寻找更大的应用场景
- 从一个用户的角度出发
3.3 何时使用包含关系?
- 当多个用例有共享行为时,使用包含关系
- 为共享行为单独创建用例,被相关用例“包含”
3.4 何时使用扩展关系?
- 一个用例与另一个用例近似,只有少许额外的活动
- 将代表普遍或基本行为的情况定义为一个用例
- 将特殊的、例外的部分定义为扩展用例
3.5 用例图中的主要图标
4、 建模工具介绍
4.1 系统建模工具的主要功能
- UML模型
- Web模型,例如Azure
- 数据库模型,例如Power Designer
- 用户自定义模型,例如Visio
画图工具
StarUML
辅助开发流程中的项目管理
- JUDE
- EA