目录

一、什么是用例

二、用例模型的表示

三、用例建模过程

第一步：找到所有的参与者和用例，识别出参与者并做简单的描述，识别出用例并做简单的介绍

第二步：编写用例，列出用例，给用例事件流程划分重要等级，按照重要程度排序详细描述事件流程

 用例文档模板

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

四、用例精讲

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

1.用文本来描述

比如用例规约中的简要描述和时间流程，一般放在用例模型概要里面。

2.用例图

简单来说，像上面图片这样包括参与者和用例名称以及一些箭头和连线所构成的就叫做用例图。

重点是其承担的角色，参与者的名字要明确角色

用一条直线表示交互——关联，有箭头的关联指出是谁发起的交互，没有箭头则表明双方都可以发起交互

用例建模的过程： 用例识别——用例图——用例提纲——用例详细规约

1.寻找参与者的方法：

• 谁/什么使用系统？ • 谁/什么从系统中获取信息？ • 谁/什么向系统提供信息？ • 公司的哪个部门会使用系统？ • 谁/什么负责系统的维护？ • 还有哪些其他系统会使用系统？

2.参与者的描述：

名称，简要描述，和用例之间的关系

3.参与者建模过程中的检查项：

• 是否找全所有的参与者？是否对系统环境中所有的角色进行了描 述和建模？ • 每个参与者是否至少与一个用例发生了交互？ • 是否可以为每一个角色找到至少两个实例？ • 不同参与者与系统的交互是否一致，扮演的角色是否相似？如果有，则应该要合并这些参与者作为同一种角色

4.寻找用例的方法：

参与者想通过这个系统达到什么目的

5.识别用例：

• 每个参与者的目标是什么？ • 为什么参与者要使用这个系统？ • 参与者是否需要对系统中数据进行创建，存储，更改，删除或 者读取的操作？为什么？ • 参与者是否需要将外部事件或发生的改变告知系统？ • 参与者是否需要知道系统内部发生的事件或改变？ • 系统是否能够应对业务中所有的正确行为与操作？

6.用例的描述：

名称，简要描述，和参与者之间的关系

7.用例的命名：

• 表明参与者的目标或者作用 • 使用主动语态：用动词起始 • 设计一系列操作流程(to-do list)

采用动宾结构，如：注册课程，选择课程等

8.用例建模过程中的检查项

• 用例建模是为了表示系统的行为。通过模型可以很容易理解系统 进行的操作 • 应该识别出所有的用例，用来表达所有的需求。 • 系统的任何一个特性都可以找到对应的用例 • 用例模型并不包含多余的行为；所有的用例可以追溯到系统的功 能性需求作为验证。 • 去掉所有的CRUD 类的用例 • 创建(Create), 查找(Retrieve), 更新(Update), 删除(Delete)。

UC_id：用例名

描述：对该用例的一句或两句的描述。

参与者：参与该用例的参与者。

包含：该用例所包含的用例，以及包含它的用例。

扩展：该用例可以扩展的用例，以及扩展它的用例。

泛化：若该用例的子用例和父用例。

前置条件：启动此用例所必须具备的条件。

细节：该用例的细节。（基本流与可选流）

后置条件：在该用例结束时确保成立的条件。

例外：在该用例的执行的过程中可能引起的例外* 。（可以把表示异常情况的事件流作为单独的用例处理）

限制：在应用中可能出现的任何限制* 。

注释：提供可能对该用例是重要的任何附加信息。

(1) 找出系统外部的参与者和外部系统，确定系统的边界和范围； (2) 确定每一个参与者所期望的系统行为； (3) 把这些系统行为命名为Use Case； (4) 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分； (5) 编制每一个Use Case的脚本； (6) 绘制Use Case图； (7) 区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单 独的Use Case处理； (8) 细化Use Case图，解决Use Case间的重复与冲突问题。

1.设定系统边界

系统边界会对用例和参与者的定义有所影响。

2.用例定义与功能分解概念不一样，不要混淆。

3.包含关系

• 当多个用例有共享行为时，使用包含关系 • 为共享行为单独创建用例，被相关用例“包含”

4.扩展关系

• 一个用例与另外一个用例近似，只有少许额外的活动 • 将代表普遍或基本行为的情况定义为一个用例 • 将特殊的、例外的部分定义为扩展用例