---
title: 用例描述
tags:
  - 架构知识
  - 软件设计理论
  - 用例分析
  - 用例模型
  - 用例图
  - 用例描述
categories:
  - - 架构知识
    - 软件设计理论
keywords: '用例,用例图,用例分析,用例描述,模版'
date: 2021-05-22 22:18:31
---

用例模型就是以用例为基本单位建立的一套系统功能展示模型，是系统中所有用例的集合，并使用统一、图形化的方式结合语言描述展示系统的功能和行为特性。<!-- more -->

用例分析是系统整体分析的起点，为未来系统模型的构建提供了方向和依据。所以要进行快速有效的用例分析，最关键的一点就是要把握用例图的绘制和用例描述。

## 用例图

### 基本元素

用例图的基本元素有四种：用例、参与者、关系和系统边界。

- **用例**一般采用水平椭圆表示，是用例模型中最重要的元素，一般表示一个系统功能。
- **参与者**用一个小人表示，是发起或者参与一个用例的外部用户或者其他软件系统等同系统进行交互的角色，不一定是一个实际用户，也可以是一个系统、外部设备或者是一个组织等。
- **系统边界**用一个矩形框表示，用于展示系统的上下文环境，是系统所包含的成分与系统外事物的分界线。
- **关系**表示参与者和用例之间的关系，通常存在关联、泛化、包含和扩展四种关系。
    - **关联**表示参与者与用例之间的通信，任何一方都可以发送和接收消息。如果消息是单向传递，那么箭头指向消息接收方。
    - **泛化**类似于继承关系，子用例与父用例相似，但行为更加特殊。箭头通常指向父用例。
    - **包含**是表示一个用例可以被分解为若干更小的步骤；基础用例可以看到它包含的用例，并且依赖这些被包含的用例的执行结果，但是两者不能访问对方的属性。包含关系一般用虚线连接，箭头指向被包含的用例，虚线上需要标记`<<include>>`字样。
    - **扩展**指用例功能的延伸，可以把新功能插入到已有用例，可以理解为为基础用例提供一个附加功能。扩展关系使用虚线连接，箭头指向被扩展的用例，虚线上需要标记`<<extend>>`字样。

以下是上面这四种用例关系的示意图。

{% oss_image use-case/用例关系.svg 用例关系示意图 750 %}

### 构建技巧

要构建一套完整有效的用例图，可以依照以下步骤来进行。

1. 分析项目目标，确定要解决的问题和解决方向。
1. 确定系统功能的参与者。
1. 根据已经寻找到的参与者寻找用例，每一个参与者的一个目标、一个任务就是一个系统用例。参与者的目标和任务必须与项目的目标和系统特性相一致。
1. 系统用例图的粒度往往不能够满足复杂系统的描述需要，所以还需要依照合适的粒度进一步细化用例。

!!! info "系统用例图"
    将系统的所有用例都集中绘制在一个图中，所形成的图形就是系统用例图。

进行用例细化也是一门非常重要的技巧，一般可以采用以下标准。

1. 不必将用例细化为单个操作，单个操作必须联合起来才能够表现出业务价值。
1. 同一业务目标不要细化成不同的用例。
1. 没有业务价值的内容不必形成用例。例如“登录”、“数据验证”、“连接数据库”等。

## 用例描述

仅有用例图来构建用例模型是不够的，还需要搭配文本形式的用例描述。虽然用例描述的形式可以多种多样，但是推荐按照以下表格中的内容来组织。

| 项目 | 内容描述 |
|---|---|
| ID | 用例的标识，用于在设计方案中快速检索用例。 |
| 名称 | 对用例内容的精确描述，需要提现用例所描述的任务。 |
| 参与者 | 列举出用例相关的所有参与者和参与者的目标。 |
| 触发条件 | 标识启动用例的事件，这个事件可以是系统外部事件也可以是内部事件，亦或是流程的第一步。 |
| 前置条件 | 描述用例能够正常启动的系统状态。 |
| 后置条件 | 描述用例执行完成以后的系统状态。 |
| 正常流程 | 在一般情况下，系统与外界的交互行为序列。 |
| 扩展流程 | 用例中可能发生的其他场景，例如出错，操作错误等。 |
| 特殊需求 | 与用例有关的特殊需求，通常是非功能性需求。 |

在书写用例描述的时候，一定需要注意以下这些事项。

1. 用例描述的核心内容是“交互”，所以需要围绕“交互”来描述场景。
1. 用例描述的级别不要过细，不要描述按钮、方法等软件实现机制。
1. 用例的正常流程必须要完整，必须包括所有的用户操作和系统反应。
1. 用例描述的形式没有限制，不过为了清晰描述，一般可以采用表格形式。