【软件工程】用例模型概念与建立

**为什么需要⽤例建模**——**描述系统的功能性需求**

• 关联干系人需要以及软件需求

• 确认与系统交互的人或对象（参与者）

• 定义系统的边界

• 捕捉和传达系统的理想行为（用例）

• 验证或确认需求

• 规划工具

*参与者（**Actor**）*

与系统交互的人或外部系统

*用例（**Usecase**）*

系统为参与者提供的有价值的服务功能

*关联（**Associa,on**）*

用例与参与者之间的交互关系

用例：定义**系统**的一系列**行为** 。通过此可为**参与者**提供**有价值**且**可观测**的结果。

**⽤例包含软件系统需求**

• 用例

• 定义一个参与者要用到的系统功能

• 描述系统为实现参与者价值所开展的行为序列

• 对参与者与系统之间的交互活动进行建模

• 从特定的用户角度出发，是完整的，实现特定用户价值的事件流

**参与者的定义：关注⾓⾊**

• 与系统交互的人

• 与系统交互的硬件组件

• 或者其他的外部系统

• 关注的重点是所承担的“角色”

• 参与者的名要明确定义其角色

**交互**——**关联（**Association**）**

• 参与者与用例之间的交互通道

• 用一条直线表示交互——关联

• 有箭头的关联指出是谁发起的交互

• 没有箭头则表明双方都可以发起交互

**构建用例模型的步骤**

• 第一步：找到所有的参与者和用例

• 识别出参与者并做简单的描述

• 识别出用例并做简单的介绍

• 第二步：编写用例

• 列出用例

• 给用例事件流程划分重要等级

• 按照重要程度排序详细描述事件流程

**参与者建模的检查项**

• 是否找全所有的参与者？是否对系统环境中所有的角色进行了描述和建模？

• 每个参与者是否至少与一个用例发生了交互？

• 是否可以为每一个角色找到至少两个实例？

• 不同参与者与系统的交互是否一致，扮演的角色是否相似？如果有，则应该要合并这些参与者作为同一种角色

**识别用例**

• 每个参与者的目标是什么？

• 为什么参与者要使用这个系统？

• 参与者是否需要对系统中数据进行创建，存储，更改，删除或者读取的操作？为什么？

• 参与者是否需要将外部事件或发生的改变告知系统？

• 参与者是否需要知道系统内部发生的事件或改变？

• 系统是否能够应对业务中所有的正确行为与操作？

**用例的命名**

• 表明参与者的目标或者作用

• 使用主动语态：用动词起始

• 设计一系列操作流程(to-do list)

• 几种表达：

• Register for Courses

• Registering for Courses

• Acknowledge Registration

• Course Registration

**用例建模过程中的检查项**

• 用例建模是为了表示系统的行为。通过模型可以很容易理解系统进行的操作

• 应该识别出所有的用例，用来表达所有的需求。

• 系统的任何一个特性都可以找到对应的用例

• 用例模型并不包含多余的行为；所有的用例可以追溯到系统的功能性需求作为验证。

• 去掉所有的**CRUD 类的用例**

• **创建(C**reate), 查找(**R**etrieve), 更新(**U**pdate), 删除(**D**elete)

**构建用例模型的步骤**

• 第一步：找到所有的参与者和用例

• 识别出参与者并做简单的描述

• 识别出用例并做简单的介绍

• 第二步：编写用例

• 找出用例

• 给用例事件流程划分重要等级

• 按照重要程度排序详细描述事件流程

**寻找用例的方法**

• 和用户交互

• 基本策略：把自己当作actor，与设想中的系统进行交互。

考虑：

• 系统交互的目的是什么？

• 需要向系统输入什么信息？

• 希望由系统进行什么处理并从它得到何种结果？

注意：确定Use Case和确定actor不能截然分开

**总结：**Use Case**模型的建立步骤**

(1) 找出系统外部的参与者和外部系统，确定系统的边界和范围；

(2) 确定每一个参与者所期望的系统行为；

(3) 把这些系统行为命名为Use Case；

(4) 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分；

(5) 编制每一个Use Case的脚本；

(6) 绘制Use Case图；

(7) 区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单独的Use Case处理；

(8) 细化Use Case图，解决Use Case间的重复与冲突问题。