重识用例（Use Case）：你需要知道的一切

作者：停下想想

2024-12-21
浙江
本文字数：3908 字
阅读完需：约 13 分钟

用例和用例图在我们日常工作中非常常见，在理解用户需求、促进项目团队沟通以及驱动软件设计和测试方面都有非常重要的作用。但也会发现一些常见的问题，缺乏对系统的了解用例和用例图规范。

用例图不规范，对包含、扩展、泛化等关系没有概念，使用混乱。
没有去区分系统用例和业务用例。
画完整体不能判断对不对，缺乏一些判断依据或原则等。
区分一些指导原则，比如应该描述什么？描述到什么程度？例如把所有系统操作列了一遍。

针对这些问题，之前刚好也看过一些资料，做简单梳理，希望对大家其有更全面的了解，内容较多点到为主。

用例起源
用例的描述
用例的定义
UML 用例图规范
用例图级别（Level)
系统用例 VS 业务用例
用例描述（文本表达）
用例 2.0（类似敏捷开发的方法体系）
最佳实践
UML 图类型

一、用例起源

其简史如下：

1986 年， Ivar Jacobson 提出了用例的概念，首次制定了用于指定用例的文本和视觉建模技术。
1992 年， Ivar Jacobson 与人合著了《面向对象的软件工程——用例驱动方法》帮助普及了捕获功能需求的技术，尤其是在软件开发中。
2000 年，Alistair Cockburn 《编写有效用例》，更是在定义用例是什么、怎么有效的书写用例方面，做了更全面的发展。
2016 年， Ivar Jacobson 与人合著《USE-CASE 2.0》，更是一套类似敏捷开发的方法。该通过支持用户故事叙述，丰富了需求收集实践。它还提供用例“切片”，以促进增量需求并实现增量实施。

Ivar Jacobson

二、用例的描述

有文本和 UML 图形两种方式：

后面逐一解释

三、用例的定义

百科上定义：

用例是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。

《编写有效用例》书中对用例定义概括是：

用例是系统中各个项目相关人员（stakeholder）就系统行为所达成的契约。
用例描述了在不同条件下，系统对某一项目相关人员的请求做出响应时发生的系统行为。
提出请求的项目相关人员被称为“主执行者”（primary actor）。
主执行者通过发起与系统的一次交互来实现某个目标。
系统对任意执行者所做出的响应，要保证所有项目相关人员的利益不受侵犯。
根据执行者做出的请求和请求涉及的条件，系统将执行不同的行为序列，
每一行为序列称为一个场景（scenario），
一个用例是多个不同场景的集合。

强调了几个关键点：

目标导向：每个用例都专注于实现一个具体的、可识别的用户目标或业务目标。
交互视角：它描述的是系统如何响应外部参与者的行为或请求，以及这些交互如何促成目标的达成。
序列性：用例描绘的是一系列事件或步骤，按照时间顺序展开，展示了从开始到结束的完整过程。
外部视角：用例是从系统外部观察者（如用户）的视角来描述系统行为，而不是深入系统的内部设计或技术细节。

四、UML 用例图规范

先简单过下 UML 用例规范，也是我们最常用的。

参与者（Actor）：参与者是系统外部的实体，可以是人、外部系统或设备，它们与系统进行交互以达成某些目标；
用例（Use Case）：系统提供的一个功能或者一个用户需求的场景，描述了系统如何响应来自参与者的请求；
系统边界（System Boundary）：明确区分系统与外部环境，显示哪些部分属于系统，哪些是外部参与者；
关系：关联（Association）、包含（Include）、扩展（Extend）、泛化（Generalization）；

日常应用需要特别注重的，要区分几个关系：

包含关系：表示一个用例包含另一个用例的行为。

对基用例来说，如果缺少了包含用例则不完整，是基用例不可缺少的一部分。

被包含用例对基用例是可见的，即基用例知道被包含用例的存在。

被包含用例通常应被两个以上的用例所包含。

2. 扩展关系：表示在特定条件下，一个用例的行为可以扩展另一个用例。

如果缺少扩展用例，基用例同样完整。

扩展用例本身具有独立的功能，而非从其他用例中抽取出来。

基用例对扩展用例是可见的，而扩展用例对基用例不可见，执行扩展用例时基用例一定会被执行。

3. 泛化关系:表示参与者或用例之间的继承关系，类似于类的泛化。

子用例和父用例相似，但表现出更特别的行为

子用例将继承父用例的所有结构、行为和关系

子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的

五、用例图级别（Level)

用例级别时描述的粒度问题，是指在用例规范中组织信息的方式；

在某种程度上，是指编写它们的详细程度。

实现正确级别的用例粒度可以简化利益相关者和开发人员之间的沟通，并改进项目规划。

1. Alastair Cockburn 的拿海洋做比喻的级别

云：是最高级别，即企业级别，整个组织中可能只有四五个用例。示例可能是广告商品、向客户销售商品、管理库存、管理供应链和优化运输。

风筝：比云低，但仍然是高级别，并提供概述。风筝用例可能处于业务单位或部门级别，是目标的摘要。示例是学生注册，或者如果与旅行公司合作：预订机票、酒店、汽车或游轮。

海浪在海平面：通常是为用户目标而创建的。这通常是用户最感兴趣，公司最容易理解的。它通常是为业务活动而编写的，每个人应该能够在 2 到 20 分钟内完成蓝色级别活动。例如，注册继续教育学生、添加新客户、将商品放入购物车并订购结帐。

鱼：用例显示了很多细节，通常是在功能或子功能级别。示例包括选择课程、支付学费、查找城市机场代码以及输入姓名后生成客户列表。

海底蛤壳：就像海底一样，是最详细的用例，处于子功能级别。示例可能是安全登录身份验证、使用动态 HTML 添加新字段或使用 Ajax 以小方式更新网页。

六、系统用例 VS 业务用例

系统用例和业务用例可以认为是两种不同的用例，也可以理解为是不同级别（level）用例。

高层用例（Business Use Cases）：从业务角度描述系统功能，主要关注的是系统如何帮助企业实现业务目标。这些用例通常不涉及技术细节，而是从业务流程和目标的角度来描述系统的功能，例子为处理订单。

用户用例（User Use Cases）：描述用户与系统的交互，通常聚焦于系统提供给用户的具体功能，例子为在线购物。

系统用例（System Use Cases）：详细描述系统内部操作，通常是开发人员用来理解和实现系统的详细设计和技术实现。这些用例包括系统如何处理数据、与其他系统交互等细节，例子为处理支付。

如果按分类分，可以认为业务用例=高层用例，其他的属于系统用例。

业务用例

业务部门或组织为其外部客户或内部特定人员（业务主角）提供有价值的服务（业务用例），强调业务操作而不是计算机系统操作，在任何目标层都可能编写业务用例，但是它们应限定在企业或组织的范围内。

研究对象：组织。
目的：明确业务组织是如何运作的。
执行者：外部客户或组织，各种操作人员为组织内业务工人。

系统用例

用户（角色）使用系统时，进行的一次比较完整的交互，并得到了有价值的结果，强调计算机系统/机械系统的操作而不是业务操作，可以在任何范围内和任何目标层上编写系统用例，企业范围内的系统用例突出了被讨论系统在企业行为中的作用。

研究对象：系统
目的：明确各种角色面对我们的系统时，双方各自要做的事和交互反馈，简言之就是明确系统究竟要做哪些事、给谁用。
执行者：执行者为操作人员所代表的岗位/系统角色或不是人的东西（外部衔接系统、自动服务、定时器）

七、文本用例描述

用例描述是对分析师为完成完整系统事务而执行的一系列步骤的书面描述。它由参与者发起，为参与者提供价值，并且是参与者在系统中工作的目标。
参与者——任何在系统外部使用系统或与系统交互以实现目标的人或系统。每个参与者都被赋予一个角色来代表他们与解决方案的交互。人物演员应该以角色的形式命名，而不应该被分配实际名称。参与者通常分为主要、次要或利益相关者
主要参与者——启动用例的参与者。
次要参与者——对主要参与者执行的动作做出反应或响应的参与者。
利益相关者——不直接与用例交互，但对用例的结果感兴趣的场外参与者。
事件流（路径） ——参与者和解决方案执行用例必须采取的步骤序列。通常，用例由主要成功路径（也称为基本或主要）、备用路径和异常路径组成。
正常路径——参与者的输入和系统的响应——代表了实现参与者目标的最常见的成功路径。
备用路径——来自参与者和系统响应的输入，代表完成参与者目标的其他不太常见的路径
异常路径——来自参与者和系统响应的输入，表示参与者的目标无法实现时的不成功路径。