在系统开发项目中，使用 UML 进行建模在从需求定义到设计、再到实现的各个阶段都扮演着极其重要的角色。
特别是在利益相关者之间形成共同理解和明确功能需求方面，使用UseCase非常有效。

然而，尽管 UML 的记法和使用示例广为人知，但对于“为什么要这样描述”“该记法基于什么语义”等 UML 的概念层面或抽象语法的理解，包括我在内都出人意料地尚未得到充分掌握。
这种概念理解的不足会直接导致建模成果物质量下降、认知不一致的发生，甚至返工增多等项目风险。

本文将依托 UML 规范 UMLspecification (version 2.5.1)，深入探讨构成 UseCase 核心的概念。
通过此举，旨在提升超越简单记法掌握的本质 UML 建模能力。
希望能为读者在需求定义阶段的建模活动中，助力产出更高质量且一致性更佳的成果物。

出处：
OMG

UML 是“Unified Modeling Language（统一建模语言）”的缩写，其目的是为系统架构师、软件工程师和软件开发人员提供用于基于软件的系统分析、设计和实现的标准化工具，并辅助对业务流程等进行建模。

UMLs 严格定义了将 UML 作为建模语言使用所需的语义和语法，并为确保不同建模工具之间模型信息的一致性而提出了以下要求。

1. UML 抽象语法（Abstract Syntax）的正式定义：构建完整 UML 模型的基础规则。
2. 各 UML 建模概念的语义（Semantics）详细说明：各要素所具备的含义和行为。
3. 用于表达各 UML 建模概念的具象语法（Concrete Syntax），即工程师可读的表示元素规范，以及将这些元素组合到各种类型图表中的规则。

本文将特别聚焦于上述 1 和 2 的抽象语法和语义，对用例图进行深入探讨。

在 UML 中，“UseCase”是概念层面的元素，“用例”（如：“顾客搜索商品”）表示具体的功能，二者在不同语境下区分提及。

根据 UMLs，UseCase 具有以下特征：

• UseCase 是明确系统应执行何种操作的手段。
• 定义 UseCase 的不可或缺概念包括 Actor（参与者）、用例（具体功能）以及 Subject（分析对象系统）。
• Subject 指用例被应用或用例用以讨论的目标系统或范围。
• 将目标系统的用户，或可能与 Subject 交互的“其他系统”描述为 Actor（Actor 不仅包括人，还包括其他系统、设备或承担特定角色的利益相关者）。

将上述概念图示如下：

图1: 用例图的基本要素和关系

用例可应用于任意数量的 Subject，通过应用用例，可将该 Subject 执行的一系列操作语言化，并明确与 Actor 之间发生的交互及操作结果。

摘自 UMLs 的用例的重要特性如下：

• 用例是 BehaviorClassifier（行为分类器）的一种。这意味着用例是定义特定行为的分类器，其行为可以通过具体的行为模型（例如：活动图、时序图、状态机图）进行详细描述。
• 每个用例都是 Subject 向 Actor 提供的有价值功能的单元，是 Subject 与 Actor 之间的主要交互手段。
• 每个用例指定了 Subject 可以与一个或多个 Actor 协同执行的操作。
• 用例不仅可以包含正常流程行为，还可以包含异常操作或错误处理。
• 要“完成”用例，必须完成该用例中定义的所有步骤。完成条件为执行后，要么①可再次执行该用例，要么②进入错误状态。

可以使用活动图或状态机图等其他 UML 图详细描述该系列操作。
根据需要，可通过前置条件、后置条件以及自然语言文本进行描述，并与其他图表结合，助力更全面的功能需求定义。

图2: 用例“拨打电话”及其关联的状态机图

Actor 指从外部利用 Subject 所提供的用例这一便利功能的实体。

在 UMLs 中，Actor 的重要特性及其与用例关联的特点如下：

• Actor 表示与系统交互的外部实体，承担向系统请求服务或从系统接收服务的角色。
• 带多重度的关联：
  • 当用例与 Actor 关联且 Actor 端多重度大于 1 时，表示有多个 Actor 实例与该用例相关联。（例如：“导弹发射”用例可能需要两名军事负责人同时进行按键操作）。
  • 当用例与 Actor 关联且用例端多重度大于 1 时，表示特定类型的某个 Actor 可以参与该类型的多个用例。
  • Actor 可以并行同时启动多个用例，也可以在不同时间启动。

UMLs 从其元模型的抽象语法视角描述 UML，尤其将用例和 Actor 作为 UseCase 建模的核心要素。以下基于 UMLs 的描述，对这些概念进行重新整理。

• 定义：表示 Actor 所视角下 Subject 提供的功能单元。描述 Subject 提供给 Actor 的一系列交互。
• 性质：
  • Classifier 的一种：定义特定行为（功能）类型的分类器。
  • BehaviorClassifier 的一种：专门定义“行为”的分类器，意味着用例可以与具体的行为描述（例如：活动图或时序图）相关联。
  • Name：用例具有唯一名称，通常以“动词+名词”形式表达具体功能（例如：“将商品加入购物车”、“计算存款”）。
  • Subject：表示用例所属的系统或组件。用例必定作为某个 Subject 的功能而存在。
  • OwnedBehavior：用例可以拥有用于详细描述其行为的模型元素（例如：活动、时序等），此用于具体化用例描述（UC 场景）。

• 定义：表示与 Subject 交互的外部实体。承担向 Subject 请求服务或从 Subject 接收服务的角色。
• 性质：
  • Classifier 的一种：定义具有共同特性的对象集合的概念，此处指承担特定角色的实体。
  • Name：以特定名词形式命名（例如：“空调系统”、“客户”）。
• 角色：明确系统（Subject）与外部的边界，阐明谁（或什么）以及以何种方式与系统交互。

• Association（关联）：
  • 关联：是 Actor 与用例之间最基本的关系，表示 Actor 发起用例或接收用例结果的含义。
  • 方向性：可在关联端添加箭头以指示信息流方向，当要展示关联不仅是连接，还要表明交互方向时，此法有效。
  • 多重度：可定义多重度，使关系具有多重性（例如：多个 Actor 实例参与）。

在用例图中，用例之间可能存在复杂关系。UMLs 中特别定义了“Extend”和“Include”两种关系。

Extend 关系用于表示从扩展用例（扩展元）到被扩展用例（扩展目标）的关系。

• Extend 指定在满足特定条件时，向被扩展用例的行为中插入附加行为。
• 当对一个或多个用例已定义的行为在某些情况下需有条件地添加行为时，使用此关系。
• 扩展元用例与扩展目标用例是独立定义的，可单独具有意义。
• 扩展元用例并不一定定义完全独立且完整的行为，而是定义一组在特定条件下增强被扩展用例执行的模块化行为。

在 UMLs 中，与 Extend 关系相关的两个概念为 ExtensionLocation 和 ExtensionPoint。

图3：ExtensionLocation 与 ExtensionPoint 的区别

5.1.1. ExtensionLocation（扩展位置）

表示在用例的基本流程（Main Flow）中，当满足特定条件时，插入扩展流程（Extension Flow）的具体位置。

ExtensionLocation 示例（用例：在线购物）

基本流程：

1. 顾客将商品加入购物车。
2. 顾客开始结算。
3. 顾客输入配送信息。
4. 顾客选择支付方式。
5. 顾客确认订单内容。
6. 顾客提交订单。

在此，我们考虑以下扩展流程：

• 库存不足时：
  • ExtensionLocation： 在基本流程第 1 步“顾客将商品加入购物车”之后
  • 扩展流程：
    1. 系统通知顾客库存不足。
    2. 顾客选择从购物车中移除商品或等待补货。
• 使用优惠券时：
  • ExtensionLocation： 在基本流程第 4 步“顾客选择支付方式”之后
  • 扩展流程：
    1. 顾客输入优惠券代码。
    2. 系统验证优惠券代码。
    3. 系统应用折扣。

5.1.2. ExtensionPoint（扩展点）

ExtensionPoint 是用例中具有唯一名称的位置，指用例行为可能被扩展的特定位置（可视为“若发生扩展，流程可能在此处分支”）。

ExtensionPoint 示例（用例：在线购物）

ExtensionPoints：

• 库存检查前处理
• 优惠券应用处理
• 订单确认前处理

基本流程：

1. 顾客将商品加入购物车。
2. 库存检查前处理
3. 系统检查库存。
4. 顾客开始结算。
5. 顾客输入配送信息。
6. 顾客选择支付方式。
7. 优惠券应用处理
8. 顾客确认订单内容。
9. 订单确认前处理
10. 顾客提交订单。
11. 系统接受订单。

※在此示例中，“库存检查前处理”、“优惠券应用处理”和“订单确认前处理”被定义为 ExtensionPoint。

Include 关系表示在用例 A 的行为中插入用例 B 的行为（A 为基本用例，B 为附加用例）。

5.2.1. Include 关系的基本原则

Include 关系表示基本用例必须执行附加用例的行为。

• 共用功能复用：将多个用例中共同执行的行为定义为独立用例，通过 Include 关系引用，避免用例内容重复，提升建模效率和可维护性。
• 基本用例明确化：将基本用例的行为拆分得更小，使用例描述更加清晰，增强可理解性。

5.2.2. Include 关系的特性

• 依赖方向：基本用例依赖附加用例，且基本用例无法在未执行附加用例的情况下完成。
• 执行时机：在基本用例执行过程中，附加用例的行为可在任意位置发生。
• 包含关系：基本用例“包含”附加用例的行为，即基本用例的执行将附加用例的行为视为一个整体流程完成。

UMLs 还定义了描述用例图时的具体表示法（具象语法）。

1. UseCase 的表示
   1. 用例使用椭圆形表示。
   2. 在椭圆内或椭圆下方书写用例名称。
   3. 根据需要，在名称上方书写立体类型关键字（如：<<primary>>）。
2. Actor 的表示
   1. Actor 使用简笔人形图标表示。
   2. Actor 名称通常写在图标的上方或下方。
   3. Actor 也可使用类图的矩形表示（参见图4）。
3. Subject（系统边界）的表示
   1. Subject 使用矩形表示，并在左上角书写名称。
   2. 在该矩形内放置用例的椭圆。
   3. 若 Subject 是具有特定立体类型的类，则在名称上方书写该立体类型关键字（参见图4）。
4. 关系的表示
   1. 用例之间的关系使用虚线箭头表示。
   2. Extend 关系时，箭头从扩展用例指向被扩展用例，并在箭头上标注 <<extend>> 立体类型。
   3. Include 关系时，箭头从基本用例指向附加用例，并在箭头上标注 <<include>> 立体类型。
   4. Extend 关系的条件或 ExtensionPoint 使用注释元素描述，并用虚线关联（参见图4）。

图4: 用例图的表示示例

本文基于 UMLs 中关于用例的描述，阐释了其抽象语法、语义以及主要关系。
不仅要了解 UML 的记法，更要理解“为什么如此表达”的概念性背景，以显著提升基于 UML 的建模质量。

在准确把握利益相关者与系统需求并落实现设计时，这种对 UML 的深层理解是不可或缺的。
希望本文能助力大家提升 UML 建模技能，并进而为项目成功贡献力量。

今后还计划从同一视角发布关于 UMLs 其他章节（如：活动图、状态机图）的解读文章。