用例图：实用指南

一个用例图是一种 UML 行为图，用于展示外部用户或系统如何与系统进行交互。它侧重于从参与者角度系统所执行的操作而非内部实现细节。

用例图在需求分析阶段尤为有用，因为它们提供了系统功能和范围的高层视图。

1. 用例图展示的内容

用例图通常包含以下内容：

• 系统边界——定义被建模系统内部包含的内容。

• 参与者——与系统交互的外部用户、组织、设备或系统。

• 用例——系统提供的目标或服务。

• 关联——参与者与用例之间的通信链接。

• 用例之间的关系——例如<<包含>>和<<扩展>>.

• 泛化——参与者或用例之间的继承关系。

用例图通常不展示以下内容：

• 算法步骤

• 数据库表

• 程序类

• 内部工作流

• 详细的用户界面布局

• 随时间推移的消息序列

这些细节更适合用活动图、类图、序列图或状态图来表示。

2. 核心概念

系统边界

系统边界是一个包围属于该系统的用例的矩形。

例如，在在线购物系统中：

+--------------------------------------+
|        在线购物系统        |
|                                      |
|  (浏览商品)                   |
|  (下订单)                       |
|  (支付)                      |
+--------------------------------------+

参与者保持在边界之外，因为它们位于系统外部。

边界有助于明确范围的系统。如果某项功能位于边界之外，则它不由被建模的系统实现。

参与者

一个参与者是指任何与系统交互以实现目标的外部实体。

参与者可以包括：

• 人类用户

• 外部应用程序

• 硬件设备

• 其他组织

• 时间或计划事件（当被建模为外部触发器时）

示例：

• 客户

• 图书管理员

• 支付网关

• 管理员

• 电子邮件服务

参与者代表一个角色，不一定是特定的人。例如，“客户”通常比“亚历克斯”更好。

参与者可以是：

• 主要参与者——发起交互以实现目标。

• 辅助参与者——为系统提供服务。

例如，客户可以发起“下订单”，而支付网关支持“处理支付”。

用例

一个用例表示系统提供的有意义的目标或服务。

良好的用例名称通常遵循以下形式：

动词 + 宾语

示例：

• 注册账户

• 搜索目录

• 提交申请

• 生成报告

• 取消预订

• 处理支付

用例应描述可观察的结果，而不是内部实现步骤。

优先选择：

下订单

而非：

验证订单对象

第二种描述的是内部操作，而非用户目标。

关联

关联是参与者与用例之间的通信链接。

它表明参与者参与或发起该用例。

客户 ---- (下订单)

关联通常不表示顺序、控制流或方向。如果交互的顺序很重要，请使用序列图或活动图。

3. 用例之间的关系

<<include>>

使用<<include>>当一个用例总是使用另一个用例时。

例如，下订单可能总是需要身份验证：

(下订单) ..> (验证客户) : <<include>>

基本用例依赖于被包含的用例。

使用include时：

• 该行为是强制性的。

• 该行为被多个用例复用。

• 提取该行为可提高清晰度。

示例：

(取款) ..> (验证卡片) : <<include>>
(查询余额) ..> (验证卡片) : <<include>>

两个用例都需要卡片验证。

<<extend>>

使用<<extend>>当额外行为是可选的，或条件性地插入到基本用例中时。

(应用折扣) ..> (下订单) : <<extend>>

折扣行为仅在满足资格条件的情况下发生。

使用extend时：

• 该行为是可选的。

• 它仅在特定条件下发生。

• 基础用例无需它即可完成。

示例：

• “添加礼品包装”扩展“下订单”。

• “申请退款”扩展“取消订阅”。

• “发送促销邮件”扩展“完成注册”。

箭头从扩展用例指向基础用例。

泛化

泛化表示参与者或用例之间的“是一种”关系。

例如：

高级客户 --|> 客户

高级客户是客户的一种类型，并继承客户的所有交互。

当多个参与者共享共同行为时，参与者泛化可能很有用：

管理员 --|> 员工
图书管理员 --|> 员工

谨慎使用泛化。如果关系仅仅是“使用”或“参与”，关联通常更为合适。

4. 主要参与者和辅助参与者

考虑一个在线支付场景：

• “客户”是主要参与者，因为他们发起购买。

• “支付网关”是辅助参与者，因为它根据系统请求处理支付。

一个简单的模型可能如下所示：

客户 ---- (下订单)
(下订单) ---- 支付网关

这种区分很有用，因为它明确了谁从用例中受益，以及涉及哪些外部系统。

5. 如何识别用例

发现用例的一个实用方法是提问：

1. 谁使用该系统？

2. 每个参与者希望实现什么目标？

3. 该系统提供哪些服务？

4. 哪些事件会触发系统行为？

5. 系统必须与哪些外部系统进行交互？

6. 哪些行为是始终必需的？

7. 哪些行为是可选的或条件性的？

对于每个参与者，列出他们的目标：

目标应对参与者具有实际意义。避免将每个微小的系统操作都转化为用例。

6. 命名指南

使用清晰、以目标为导向的名称。

良好示例：

• 创建账户

• 更新个人资料

• 提交索赔

• 跟踪货运

• 批准请求

• 生成发票

避免使用模糊的名称：

• 系统处理

• 处理数据

• 用户功能

• 运行操作

避免过多的技术细节：

• 执行 SQL 查询

• 调用 REST 端点

• 实例化支付服务

这些可能是有效的实现步骤，但通常不适合作为高层级用例。

7. 示例：图书馆管理系统

假设图书馆系统支持以下功能：

• 会员搜索图书

• 会员借阅图书

• 会员归还图书

• 图书管理员管理目录

• 逾期通知

• 罚款支付处理

可能的参与者：

• 会员

• 图书管理员

• 通知服务

• 支付服务

可能的用例：

• 搜索目录

• 借阅图书

• 归还图书

• 计算罚款

• 缴纳罚款

• 管理目录

• 发送逾期通知

关系：

• 借书用例包含检查会员资格用例。

• 借书用例包含检查图书可用性用例。

• 归还图书用例包含计算罚款用例。

• 缴纳罚款用例与支付服务交互。

• 发送逾期通知用例与通知服务交互。

8. PlantUML 示例

以下 PlantUML 代码为图书馆系统创建了用例图：

@startuml
left to right direction

title Library Management System - Use Case Diagram

actor Member
actor Librarian
actor "Notification Service" as Notification
actor "Payment Service" as Payment

rectangle "Library Management System" {

  usecase "Search Catalog" as UC_Search
  usecase "Borrow Book" as UC_Borrow
  usecase "Return Book" as UC_Return
  usecase "Check Membership" as UC_CheckMember
  usecase "Check Book Availability" as UC_CheckAvailability
  usecase "Calculate Fine" as UC_CalculateFine
  usecase "Pay Fine" as UC_PayFine
  usecase "Manage Catalog" as UC_ManageCatalog
  usecase "Send Overdue Notification" as UC_Notify
}

Member --> UC_Search
Member --> UC_Borrow
Member --> UC_Return
Member --> UC_PayFine

Librarian --> UC_ManageCatalog
Librarian --> UC_Borrow
Librarian --> UC_Return

Payment --> UC_PayFine
Notification --> UC_Notify

UC_Borrow ..> UC_CheckMember : <<include>>
UC_Borrow ..> UC_CheckAvailability : <<include>>
UC_Return ..> UC_CalculateFine : <<include>>

UC_Notify ..> UC_Return : <<extend>>

@enduml

9. 示例说明

参与者

actor Member
actor Librarian
actor "Notification Service" as Notification
actor "Payment Service" as Payment

该图建模了两个人类参与者和两个外部服务。

别名，例如as Notification使较长的名称在后续引用时更加简便。

系统边界

矩形“图书馆管理系统”{
    ...
}

该矩形定义了系统的范围。矩形内的用例由图书馆系统提供。

参与者关联

参与者 --> 用例_搜索
参与者 --> 用例_借阅

这些关联表明，成员可以搜索目录并借阅图书。

在基本用例图中，箭头方向通常不具有语义重要性，其主要作用是使图表更易读。

包含关系

用例_借阅 ..> 用例_检查成员 : <<include>>
用例_借阅 ..> 用例_检查可用性 : <<include>>

借阅图书始终需要成员资格检查和可用性检查，因此这些被建模为包含用例。

扩展关系

用例_通知 ..> 用例_归还 : <<extend>>

这表明逾期通知行为是与归还图书相关联的附加行为。

然而，在真实的需求模型中，更自然的设计可能是将“发送逾期通知”与计划流程或参与者（如“图书馆调度员”）关联起来。最佳关系取决于实际的业务规则。

10. 更详细的用例规格说明

图表提供概览，但每个重要用例通常应有文本规格说明。

用例：借阅图书

用例图不应试图包含所有细节。该图提供地图，而规范提供行为。

11. PlantUML 语法参考

声明参与者

actor Customer
actor "Payment Gateway" as Gateway

声明用例

usecase "Place Order" as PlaceOrder
usecase "Process Payment" as ProcessPayment

创建系统边界

rectangle "在线商店" {
    usecase "浏览商品" as Browse
    usecase "下订单" as Order
}

连接参与者与用例

Customer --> Browse
Customer --> Order

包含

Order ..> ProcessPayment : <<include>>

扩展

ApplyCoupon ..> Order : <<extend>>

参与者泛化

PremiumCustomer --|> Customer

包分组

包可以直观地分组相关用例：

rectangle "银行系统" {
  package "账户管理" {
    usecase "开立账户" as OpenAccount
    usecase "关闭账户" as CloseAccount
  }

  package "支付" {
    usecase "转账" as TransferFunds
    usecase "支付账单" as PayBill
  }
}

注释

note right of PlaceOrder
  客户在下单前必须经过身份验证。
end note

12. 改进图表布局

PlantUML 会自动布局图表，但多种技术可提升可读性。

控制方向

从左到右方向

当参与者应出现在两侧、用例位于中心时，这通常非常有用。

其他常见方向包括：

从上到下方向

使用别名

无需重复冗长的名称：

usecase "验证客户身份" as VerifyIdentity

然后引用：

RegisterAccount ..> VerifyIdentity : <<include>>

分组相关用例

使用包或嵌套矩形来分隔功能区域：

package "订单管理" {
    usecase "创建订单" as CreateOrder
    usecase "取消订单" as CancelOrder
}

避免过多交叉

当线条交叉过多时，图表会变得难以阅读。你可以通过以下方式改进：

• 将相关参与者放置在靠近其用例的位置

• 将用例分组到包中

• 将一个大型图表拆分为多个小型图表

• 使用别名以实现清晰的引用

• 避免不必要的关系

13. 常见错误

将内部功能建模为用例

这通常过于技术化：

验证数据库连接
序列化请求
调用支付 API

优先选择具有外部意义的目标：

进行支付
提交申请
生成报告

将每个参与者都视为人

外部系统和设备也可以作为参与者：

• 支付网关

• 身份提供商

• 仓储系统

• 条码扫描器

• 通知服务

使用include表示可选行为

如果行为是可选的，请使用扩展 而不是 包含.

错误：

下订单 ..> 应用优惠券：<<包含>>

如果应用优惠券是可选的，请使用：

应用优惠券 ..> 下订单：<<扩展>>

使用 扩展 表示强制行为

如果某种行为总是发生，通常应使用 包含.

下订单 ..> 验证客户：<<包含>>

无意义地直接连接用例

两个用例之间的连线应表示有效的 UML 关系。避免随意连接，仅暗示用例之间存在某种关联。

创建一张巨型图表

用例图应在高层级上清晰传达信息。如果它包含数十个参与者和用例，请创建多个按子系统或业务领域组织的图表。

展示顺序

用例图不显示一个用例发生在另一个用例之前。如需展示顺序，请使用序列图或活动图。

14. 何时使用其他 UML 图表

用例图最适合表示系统范围和用户目标。当需要更多细节时，应将其与其他图表结合使用：

15. 推荐的建模过程

1. 定义系统边界。

2. 识别所有外部参与者。

3. 识别每个参与者的目标。

4. 将这些目标转换为用例。

5. 将参与者与其参与的用例连接起来。

6. 识别必须的可复用行为，并使用以下符号对其进行建模：<<include>>.

7. 识别可选或条件行为，并使用以下符号对其进行建模：<<extend>>.

8. 仅在存在真实的“是-a”关系时才添加泛化。”

9. 与利益相关者一起审查该图。

10. 为重要用例添加文本规范。

11. 如果图表变得拥挤，请将其拆分。

16. 紧凑的 PlantUML 模板

您可以将其作为起点：

@startuml
left to right direction

title 系统用例图

actor 用户
actor "外部系统" as ExternalSystem

rectangle "系统名称" {
  usecase "主要用户目标" as MainGoal
  usecase "所需共享行为" as RequiredBehavior
  usecase "可选行为" as OptionalBehavior
}

用户 --> MainGoal
ExternalSystem --> MainGoal

MainGoal ..> RequiredBehavior : <<include>>
OptionalBehavior ..> MainGoal : <<extend>>

@enduml

核心原则是建模外部可见的目标而非内部实现细节。一个优秀的用例图能让人立即理解系统边界、参与者、功能以及重要依赖关系。

参考资料