文章目录
一、用例建模概念
1.用例在需求管理过程中的作用
- 在一个项目开展的过程中，我们可以通过一系列的需求活动管理去挖掘系统的相关信息，通过分析问题理解干系人的需求。
- 在定义系统的过程中，我们可以利用简略的用例规约对系统的功能和业务过程进行表示
- 融入领域相关信息后，对系统进行细化完善，形成更加详细的用例规约描述。
在以上这样的过程中，我们逐步形成了完整的用例模型进而可以管理变化的需求
2.为什么需要用例建模——描述系统的功能性需求
- 关联干系人需要以及软件需求
- 确认与系统 交互 的人或对象（参与者）
- 定义系统的 边界
- 捕捉和传达系统的理想行为（用例）
- 验证或确认 需求
- 规划工具 ，辅助规划开发过程
3.用例模型的表示——文本描述
用例图有利于宏观的了解系统，文本描述则给出了参与者和用例的具体信息。而对用例进行描述是用例建模中更为重要的部分。
文本描述中包含用例模型概要以及用例规约描述
- 模型概要中简要介绍了系统的功能与意义，列出相关的参与者和用例。
- 在每个具体的用例规约中，将详细描述用例中会发生什么操作或事件，涉及的非功能性需求和规则约束等，也就是要对每个用例的事件流进行描述。
用例模型的另一种表示是用例图
4.用例图的主要元素
（1）什么是用例？
“定义系统的一系列行为”应当是动宾结构
用例表示的这个功能实际上涵盖了一系列的原子操作，代表着参与者和系统之间的交互过程，这些操作是原子性的，每一个都应该是完全执行或完全不执行的。
用例往往用来和用户确认需求，辅助开发团队规划开发进度，因此定义的用例的服务对象一定是系统最终的使用用户，也就是参与者。
总结
- 定义一个参与者要用到的系统功能
- 描述系统为实现参与者价值所开展的行为序列
- 对参与者与系统之间的交互活动进行建模
- 从特定的用户角度出发，是完整的，实现特定用户价值的事件流
（2）参与者的定义：关注角色
- 与系统交互的人
- 与系统交互的硬件组件
- 或者其他的外部系统
- 关注的重点是所承担的“角色”
- 参与者的名要明确定义其角色
（3）交互——关联（Association）
- 参与者与用例之间的交互通道
- 用一条直线表示交互——关联
- 有箭头的关联指出是谁发起的交互
- 没有箭头则表明双方都可以发起交互
箭头的使用约束：
- 如果图中标明了箭头相应的信息也应该在用例文本描述中有所体现，标志在何种情况下进入用例
- 箭头表示并不是必须的，仅当需求中有明确的定义时才进行使用
- 一种异常的表示，是如果有两个或两个以上的箭头指向了同一个用例，在大部分情形下是一个指向用例的箭头，其余的箭头应该是由用例指出或无方向
- 箭头的方向只表示消息的传递方向，而不表示那个参与者创建用例或者是用例服务的受益方
4.每一个交互——关联代表一个完整的对话
5.场景(Scenario)是用例的实例
二、用例建模过程
构建用例模型的步骤
- 第一步：找到所有的参与者和用例
- 识别出参与者并做简单的描述
- 识别出用例并做简单的介绍
第二步：编写用例列出用例给用例事件流程划分重要等级按照重要程度排序详细描述事件流程
1.参与者
（1）寻找参与者
- 谁/什么使用系统？
- 谁/什么从系统中获取信息？
- 谁/什么向系统提供信息？
- 公司的哪个部门会使用系统？
- 谁/什么负责系统的维护？
- 还有哪些其他系统会使用系统？
（2）识别参与者——是谁与系统进行交互？
上图，在中心选课系统中，学生并不是参与者，而在在线选课系统中，学生是参与者之一。
（3）参与者的描述
- 参与者在定义时，考虑的是用户的身份，因此参与者的名称应该要明确指明参与者与系统交互时的身份。同时应该要注意参与者的命名应该要唯一，可以与其他参与者进行区分。
- 随后要对参与者进行简要的描述，具体的内容包括这个参与者代表了哪些用户，为什么会需要这个参与者，参与者对于系统的需求具体的是什么
- 一类特殊的参与者——调度器
（4）参与者建模的检查项
- 是否找全所有的参与者？是否对系统环境中所有角色进行了描述和建模？
- 每个参与者是否至少与一个用例发生了交互？
- 是否可以为每一个角色找到至少两个实例？
- 不同参与者与系统的交互是否一致，扮演的角色是否相似？如果有，则应该要合并这些参与者作为同一种角色
2.用例
（1）寻找用例
- 在寻找参与者的同时，要描述系统为参与者提供的服务以至参与者如何与系统交互，这个就是寻找用例的过程。
- 基本策略：把自己当作actor，与设想中的系统进行交互
- 注意：确定Use Case和确定actor不能截然分开
（2）识别用例
- 每个参与者的目标是什么？
- 为什么参与者要使用这个系统？
- 参与者是否需要对系统中数据进行创建，存储，更改，删除或者读取的操作？为什么？
- 参与者是否需要将外部事件或发生的改变告知系统？
- 系统是否能够应对业务中所有的正确行为与操作？
（3）用例的描述
- 用例的名称应该是唯一的，清楚地表达了参与者与系统交互的目标，所以要用动宾结构作为名称
- 用例的简要描述中介绍了参与者和系统如何交互，系统需要进行哪些原子操作等。
- 最后需要建立用例与参与者的关系
（4）用例的命名
- 表明参与者的目标或者作用
- 使用主动语态：用动词起始
- 设计一系列操作流程（to-do list）
（5）用例建模过程中的检查项
- 用例建模是为了表示系统的行为。通过模型可以很容易理解系统进行的操作
- 应该识别出所有的用例，用来表达所有的需求。
- 系统的任何一个特性都可以找到对应的用例
- 用例模型并不包含多余的行为；所有的用例可以追溯到系统的功能性需求作为验证。
- 去掉所有的CRUD 类的用例
- 创建(Create), 查找(Retrieve), 更新(Update), 删除(Delete)
3.用例描述扩展
构建用例模型的步骤
第一步：找到所有的参与者和用例识别出参与者并做简单的描述识别出用例并做简单的介绍
- 第二步：编写用例
- 列出用例
- 给用例事件流程划分重要等级
- 按照重要程度排序详细描述事件流程
在第一步的用例简单描述的基础上进行扩展形成用例提纲
用例提纲涵盖了大致的事件流程，随后将其细化增加条件说明等，形成更加详细的规约。
用例的全生命周期
（1）用例简述的例子
（2）用例概述的例子
（3）详细用例的规约的例子
（4）用例文档模板
4.总结：Use Case模型的建立步骤
- 找出系统外部的参与者和外部系统，确定系统的边界和范围；
- 确定每一个参与者所期望的系统行为；
- 把这些系统行为命名为Use Case；
- 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分；
- 编制每一个Use Case的脚本；
- 绘制Use Case图；
- 区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单独的Use Case处理；
- 细化Use Case图，解决Use Case间的重复与冲突问题。
三、用例建模精讲（细节）
1.设定系统边界
- 系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线
- 系统边界会对用例以及Actor的定义有所影响
2.不要把用例定义成功能分解
- 功能分解：将问题分解为粒度较小，独立的部分
- 不同的模块协同工作，体现系统的功能。
- 通常，一些功能分解并没有实际的意义。
- 不同的模块协同工作，体现系统的功能。
- 用例:
- 不是功能分解的过程！
- 综合所有功能一起描述系统如何使用。
- 需要包含语境信息
（1）如何避免功能性分解
3.何时使用包含关系？
- 当多个用例有共享行为时，使用包含关系
- 为共享行为单独创建用例，被相关用例“包含”
4.何时使用扩展关系？
- 一个用例与另外一个用例近似，只有少许额外的活动
- 将代表普遍或基本行为的情况定义为一个用例
- 将特殊的、例外的部分定义为扩展用例
5.用例图中的主要图标
扫一扫
2634
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
