de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

UML 图表全面指南

引言

统一建模语言（UML）已成为跨行业可视化、规范和记录软件系统的事实标准。UML 的核心并非一种僵化的开发方法论，而是一种灵活的视觉语言，旨在弥合抽象需求与具体实现之间的差距。UML 2.0 通过将图的类型组织为两个互补类别来明确这一目的：结构图，用于捕捉系统的静态架构和物理关系，以及行为图，用于建模组件如何交互、状态如何变化以及逻辑如何随时间执行。本指南基于《UML 2.0 快速入门》（O’Reilly）中概述的基础原则，全面介绍了每种主要 UML 图表类型的核心概念、符号规则和实际应用场景。无论您是在设计面向对象系统、绘制部署拓扑图，还是建模复杂的业务工作流程，掌握每种图表的适用时机与使用方法，都将帮助您清晰、精确且有共识地传达技术解决方案。UML 2.0 快速入门（O’Reilly），本指南全面介绍了每种主要 UML 图表类型的核心概念、符号规则和实际应用场景。无论您是在设计面向对象系统、绘制部署拓扑图，还是建模复杂的业务工作流程，掌握每种图表的适用时机与使用方法，都将帮助您清晰、精确且有共识地传达技术解决方案。

概览

UML 2.0 将图表分为两大主要类别:

类别 用途
结构图 捕捉元素的物理组织结构——对象之间的相互关系
行为图 关注元素如何交互、状态如何变化以及行为如何随时间演变

💡 核心原则：UML 模型由一个或多个图表组成。每个图表代表系统建模中的一个特定视图或关注点，即被建模系统的特定视图或关注点。单个元素通常会出现在多个图表中。

🔷 结构图

结构图用于建模系统的静态架构——关注的是“是什么”，而非“如何实现”。

1. 类图

用途: 模型类、接口及其静态关系。

关键元素:

  • 具有属性和操作的类

  • 接口和实现关系

  • 关联、聚合、组合和泛化

  • 可见性修饰符（+, -, #, ~)

  • 多重性规范（1, 0..*, 1..5)

使用示例:何时使用:

类的构造型和类型

该图使用构造型（用尖括号内的文本表示，例如 <<entity>>）来对每个类的角色进行分类：

  • 边界类（<<边界>>): 这些处理系统与其参与者（用户或外部系统）之间的交互。

  • 示例： 控制台窗口和对话框.

  • 控制类（<<控制>>): 这些管理应用程序的协调、事务和业务逻辑流程。

  • 示例： 绘图上下文和数据控制器.

  • 实体类（<<实体>>): 这些代表系统所跟踪的核心数据或持久信息。

  • 示例： 框架, 窗口, 事件, 形状, 圆形, 矩形, 多边形，以及点.

  • 抽象类：该形状类代表一个抽象概念。它作为特定形状的基础蓝图，不能单独直接实例化。

类的结构

标准的UML类框被划分为多个部分。以圆形类为例：

  • 类名：位于顶部区域（圆形).

  • 属性：位于中间区域，表示数据字段。

  • -半径：浮点数（减号-表示私有属性）。

  • -中心：无符号整数

  • 操作（方法）：位于底部区域，表示行为或函数。

  • +area(半径: 浮点数) : 双精度浮点数 (加号+ 表示一个公共方法)。

  • +circum(), +setCenter()，以及 +setRadius().

关系与链接

连接类的线条和箭头定义了它们如何相互作用和彼此依赖：

泛化（继承）

用一条实线和一个 空心箭头 指向父类。这表示一种“是-一种”关系，子类从父类继承属性和行为。

  • 窗口 继承自 框架.

  • 控制台窗口 和 对话框 继承自 窗口.

  • 圆, 矩形，以及 多边形从抽象类继承形状（例如，一个圆是一个形状）。

聚合

用一条实线表示，一端带有空心菱形在容器端。这表示一种松散的“拥有”或整体-部分关系，其中子对象可以独立于父对象存在。

  • 窗口聚合形状（多重性1到*）。一个窗口可以包含多个（*）形状，但如果窗口关闭，这些形状在概念上仍然可以存在于内存或其他上下文中。

组合

用一条实线表示，一端带有实心（黑色）菱形在容器端。这表示一种强“拥有”关系，且生命周期一致——如果容器被销毁，其组成部分也会被销毁。

  • 圆由……组成点对象（多重性1到*). 圆的存在离不开其中心点或边界点；破坏圆的同时也破坏了这些特定点的引用。

依赖

由一个虚线箭头。它表示一个类依赖于另一个类，这意味着对目标类的更改可能会影响源类。

  • 窗口依赖于事件（由指向事件的虚线箭头表示）。窗口依赖于事件触发来执行诸如handleEvent().

关联

由一条简单的实线表示。它表示一种结构关系，即一个类的对象与另一个类的对象相连接。

  • 对话框与数据控制器，意味着它们相互之间进行通信以传递信息或协调行为。

文档元素

  • 注释：该图包含一个带折角的注释框，通过虚线连接到窗口类。它提供了人类可读的上下文信息：“应用程序的主窗口。”

What is Class Diagram?

  • 设计面向对象的软件架构

  • 记录领域模型

  • 生成代码骨架

2. 组件图

目的: 展示实现单元的组织结构和依赖关系。

关键元素:

  • 组件（以 «component»)

  • 提供的/需要的接口（球与插座符号）

  • 组装连接器和依赖关系

  • 工件（编译输出：JAR、DLL、可执行文件）

示例用法:何时使用:

组件与模块边界

该图的核心概念是组件，即系统中一个自治且模块化的单元，它封装其内容并通过清晰的接口展现其行为。较大的外边界代表整体的终端组件，它充当子系统或容器。在此容器中包含较小的、专门的内部组件——即安全检查, 工作人员, 缺陷，以及地图。这些内部单元中的每一个都代表一个模块化的软件组件或数据管理逻辑，它们协同工作以履行终端的责任。

接口作为契约

组件不会直接暴露其内部逻辑；相反，它们通过明确定义的接口进行交互，这些接口作为架构契约。

  • 提供的接口： 用“棒棒糖”或圆形符号表示，这些符号代表组件实现并提供给其环境的服务、数据或操作。例如，外部的终端组件会暴露外部提供的接口，如状态, 详细信息，以及检查项目，表明外部客户端可以从它请求什么。

  • 所需的接口： 用“插座”或半圆形符号表示，这些符号指明组件为正常运行所需从其他实体获取的服务或数据。在图的右侧，终端组件明确暴露了对账户和检查编号的所需接口，表明其对外部子系统的依赖关系。

端口与内部布线

为了在保持封装性的同时管理数据和控制的流动，系统使用端口和委托关系。

  • 端口： 位于组件边界上的小方块代表端口。它们作为不同的交互点，使组件的内部结构与外部世界相连。端口使组件能够将其内部布线与外部环境隔离，这意味着内部组件可以被替换或修改，而不会改变父组件对外呈现的方式。

  • 委托与组装： 在终端内部，线条连接这些接口以形成结构组装。外端口上的提供接口会将传入的请求直接委托给内部组件的提供接口（如状态和详细信息通向安全检查的路径所示）。相反，内部组件将其所需的插座接口直接连接到相邻组件的提供型棒棒糖接口上。例如，安全检查组件依赖于检查员接口，该接口由员工，其中缺陷详情 接口由 缺陷，以及位置 接口由 地图，从而创建一个紧密协调但松散耦合的内部生态系统。

What is Component Diagram?

  • 规划模块化系统架构

  • 管理构建依赖

  • 记录可重用组件库

3. 组合结构图（UML 2.0 中新增）

关键元素:

  • 部分（具有整体-部分关系的属性）

  • 端口（与提供的/需要的接口进行交互的点）

  • 连接器（部分之间的运行时链接）

  • 协作实例

示例用法：建模一个汽车:

封装分类器（类）

外层矩形表示包含的分类器，在此情况下是汽车类。在组合结构图中，此边界充当容器，封装系统的内部运行时配置。它定义了各个实例协作以实现更广泛行为目的的上下文，将“汽车”内部工作原理的复杂性隐藏于外部实体之外。

部分（内部结构）

汽车边界内的内部矩形表示部件。一个部件解释了在包含分类器执行过程中，一组实例所扮演的角色。与展示静态编译时关系（如标准类图）不同，这些部件表示运行时实例填充特定的架构槽位：

  • -t：变速器：一个扮演变速器系统角色的实例。

  • -e：发动机：一个扮演发动机动力源角色的实例。

  • -s：转向系统：一个扮演转向机构角色的实例。

冒号表示法表明，这些是各自类定义的结构性角色，精确地定义了运行中的汽车内部必须存在的组件。

端口与边界

嵌入在外分类器边界和内部部件边界上的小方块表示端口。端口是独立的交互点，将分类器的内部结构与其外部环境解耦。

  • 汽车边界上的外部端口——例如：车轮, ：油门踏板，以及：方向盘——展示了汽车如何与外部世界或物理环境交互，而无需暴露哪些内部部件正在处理这些交互。

  • 内部部件上的端口（如变速器或发动机模块上的端口）控制这些子系统之间或与父边界之间的通信方式。

连接器与内部布线

连接端口的实线表示连接器。连接器定义了部件之间或部件与外部端口之间在运行时的通信路径。

  • 委托连接器：将容器的外部端口直接连接到部件的内部端口。例如，外部: 轮子 接口直接连接到 变速器，以及外部的 : 方向盘 直接连接到 转向系统。这确保了外部刺激能够无缝地传递给正确的内部执行者。

  • 组件连接器： 将内部组件连接在一起以实现协作。变速器与发动机之间的连接器表明，这两个不同的运行角色直接交换信号、数据或机械力，使汽车作为一个整体正常运作。变速器 与 发动机 表明这两个不同的运行角色直接交换信号、数据或机械力，使汽车作为一个整体正常运作。

何时使用:

  • 记录设计模式

  • 建模复杂的内部协作

  • 连接类设计与组件实现

4. 部署图

目的: 将软件构件映射到硬件执行环境。

关键元素:

  • 节点（设备、执行环境）

  • 构件（可部署单元）

  • 节点之间的通信路径

  • 部署规范（配置细节）

示例用法:何时使用:

节点与物理基础设施

与描述代码布局或类结构的逻辑设计图不同，部署图关注的是硬件拓扑。主要的构建块是节点，它们在视觉上以三维立方体表示。节点展示了软件元素实际运行的物理计算资源或执行环境：

  • <<处理器>> 节点： 立方体使用以下类型标注：<<处理器>>（例如缓存服务器, 主服务器，以及通用的服务器块）表示具有计算能力、内存和处理能力的节点，能够执行软件二进制文件。

  • <<网络>> 节点： 标有本地网络的细长立方体代表通信路径或路由基础设施，而非单个计算机。它表示物理骨干网络，使连接的处理器能够交换数据包流。

  • 设备节点： 未使用类型标注的节点，如互联网和调制解调器银行代表边界硬件组件或外部物理基础设施，用于将外部流量路由到核心系统环境中。

关联与通信路径

连接三维立方体的实线表示关联在部署图中，这些关联描绘了节点之间的物理通信路径、网络链接或硬件连接。

  • 之间的连线互联网和调制解调器银行展示了外部公共数据进入硬件堆栈的入口点。

  • 从调制解调器银行延伸至缓存服务器描绘了入站流量向下到边缘缓存层的物理路由路径。

  • 连接缓存服务器和底层的主服务器集群与本地网络建立了内部组件通过共享的高速本地总线或网络交换机基础设施进行通信的方式。

拓扑分层与冗余

图中节点的排列明确展示了用于高可用性和负载分发的部署拓扑及架构设计选择。

  • 边缘缓存层：在入口调制解调器硬件正下方，有两个独立且并行的缓存服务器节点。这种配置直观地展示了冗余的边缘层，旨在将入站流量负载进行分发，并在请求到达深层基础设施之前缓存资源。

  • 内部服务器集群：位于堆栈底部，通过本地网络连接，是一个核心服务器集群。主服务器 以及相邻的通用 服务器 节点以可视化方式展示主从或主备架构布局，确保数据持久性和重计算负载在内部数据中心环境中安全协调。

What is Deployment Diagram?

用途: 建模分类器和复杂模式的内部结构。

  • 规划系统基础设施

  • 记录分布式架构

  • 指定故障转移和冗余策略

5. 包图

用途: 通过逻辑分组来组织和管理命名空间。

关键元素:

  • 包（带标签的矩形）

  • 导入/访问关系（«导入», «访问»)

  • 合并关系（«合并»)

  • 可见性（+ 公共，- 私有）

示例用法:

子系统和包边界

该图示大量依赖“文件夹”符号来表示设计元素的逻辑分组。

  • 子系统： 大型外部文件夹被定义为 <<子系统>> 订单管理 表示物理系统中的一个主要且封装的行为单元。它作为一个高层容器，将执行订单管理所需的相关组件和包组合在一起。

  • 包： 子系统内部和外部的较小文件夹（例如 UI, 订单处理，以及 GUIManager）是标准包。它们用于将元素组织成可管理的组，建立命名空间，并定义架构内可见性的边界。

依赖关系与分层

虚线箭头表示 依赖关系，表明一个包（目标）的更改可能会影响源包（起始包）的功能。

  • 内部依赖关系： 在订单管理子系统内部，可以清晰地看到自上而下的架构分层。UI 包依赖于 订单处理，而后者又依赖于 价格计算器 和 外部存储。这表示一种架构流，其中高层的展示元素依赖于核心业务逻辑和数据访问层。

  • 对外部包的依赖： 包也可以依赖于其直接子系统边界之外的元素。例如，UI 包依赖于外部 GUIManager。类似地，底部的 随机存储 和 流存储 包跨越子系统边界依赖于外部数据结构，突显了该子系统如何融入更大的软件生态系统。

抽象与继承（泛化）

该图使用特殊样式和关系箭头，展示应用于模块化架构的抽象设计模式。

  • 抽象包与具体包： 包含抽象元素或定义类似接口结构的包以斜体名称表示（例如 外部存储 和 存储管理）。相反，包含操作代码实现的包，如 仓库 和 文件存储，使用标准文本表示它们是具体包。

  • 泛化： 用一条实线和一个开口的空心三角形指向父包来表示。这表明存在继承或实现关系。在子系统内部，随机存储 和 流存储 专门化或实现抽象的 外部存储 接口。在子系统外部，具体的 仓库 和 文件存储 包将抽象化向上推广 存储管理 包，展示如何在包级别对多态行为和结构分类进行建模。

    What is Package Diagram?

  • 何时使用:

  • 管理大型代码库

  • 定义模块边界

  • 控制编译依赖

6. 对象图

目的: 展示特定时刻实例及其链接的快照。

关键元素:

  • 对象（下划线名称：myCar:Car)

  • 对象实例之间的链接

  • 运行时的属性值

示例用途:

对象与具体实例

与展示抽象蓝图级配置的类图不同，对象图捕捉的是内存中实际存在的实例。对象用矩形表示，其名称始终加下划线，以表示实例化。

  • 命名对象： 它们遵循以下语法 实例名称 : 类名称。例如，c : Company 表示名为“c”的特定公司实例，而 p : Person 表示名为“p”的特定个人实例。

  • 匿名对象： 当省略特定实例标识符或与场景无关时，仅提供类名，并以冒号开头（例如，: 联系信息）。这表示存在一个具体的联系信息实例，并与结构相关联，但在当前上下文中无需使用唯一的变量名。

状态和属性值

对象矩形的下部包含其特定状态，由该时刻分配给其属性的显式值定义。这些条目不只列出数据类型，而是使用属性 = 值赋值格式来反映实际情况：

  • 部门实例d1持有属性值name = 销售.

  • 另一个不同的部门实例d2持有值name = 研发.

  • 人员实例p持有完整的一组状态数据，描绘出一个特定的个人资料：name = 德里克, employeeID = D-12821，以及title = 经理.

链接和关系

连接对象的实线表示链接链接是类之间定义的关联的具体实例。如果类图表明公司拥有部门，那么对象图将展示它们之间的实际运行时连接。

  • 公司实例c与部门实例d1（销售）以及d2（研发）。

  • 该图还展示了层次化的实例连接，其中d1 : 部门（销售）向下连接到一个同样被定义为部门的子部门实例（name = 美国销售).

  • 最后，人员实例p（德里克）与美国销售部门实例相连，同时保持与一个匿名：联系信息实例相连，该实例包含他的实际地址。

何时使用:

  • 验证类图设计

  • 调试复杂的对象关系

  • 展示示例运行时状态

🔶 行为图

行为图用于建模动态方面——系统随时间变化的行为。

7. 活动图

目的：用于建模工作流程、业务流程和算法逻辑。

关键元素:

  • 操作（圆角矩形）

  • 控制节点：初始、决策、合并、分叉、汇合、最终

  • 对象节点和插槽

  • 分区（泳道）用于责任分配

  • 异常处理程序和可中断区域

示例用途：订单处理工作流

结构组织（泳道和分区）

该图垂直划分为大型列，这些列可互换地称为泳道或分区。这些边界对包含在其中的操作的责任进行分类，将步骤映射到特定角色或业务单元：

  • 客户销售接口：负责面向客户的生命周期，处理客户初始化、备用路由和最终展示。

  • 方案负责人：负责核心规划、运营分析以及正式方案数据结构的编制。

  • 报价负责人：专注于纯粹的财务估值和准备具体的报价指标。

控制流和操作状态

逐步的过程执行由控制节点和有向路径引导。

  • 初始节点：由顶部的实心黑圆圈表示，这表示整个活动工作流的起点。

  • 操作： 圆角矩形（例如，初始化联系人, 搜索替代方案，以及汇总附加信息) 表示执行序列中的单一、不可分解的步骤或任务。

  • 控制流： 连接各元素的实线箭头决定了工作流的顺序进展，明确指出哪一项操作必须完成之后，下一项才能开始。

  • 活动最终节点： 底部的靶心符号（实心圆位于空心环内）标志着整个过程执行的绝对终止点。

路由与带守卫逻辑（决策节点）

菱形符号表示决策节点，用于在工作流中建模条件分支。

  • 输入的特定条件决定了传入的控制路径被拆分为多个互斥的传出路径。

  • 决定选择哪条路径的条件被包含在方括号中，称为守卫条件（例如[已接受], [已拒绝]，以及[与另一供应商合并或更改需求])。该过程在运行时评估这些守卫条件，以将执行引导至相应的功能路径。

并行处理（分叉与合并节点）

图中的实心黑色条形充当同步点，用于管理并发或并行的执行流。

  • 分叉节点（图示指针中标记为流程节点）： 一个传入的控制流进入条形后，分裂为多个独立的并发执行线程。在此处，创建项目计划后，流程分叉，使提案负责人能够执行分析和交付规划，同时报价负责人同步处理报价准备。

  • 合并节点： 一个同步条形，将多个并发路径重新合并为单一控制流。在所有传入的并行流都成功到达该条形之前，流程无法通过合并节点。所有传入的并行流都已成功到达条形，确保在继续编译最终包之前，报价汇总和提案起草已完全完成。

数据集成（对象节点）

标准矩形表示对象节点，用于将数据流引入以控制为导向的活动图中。

  • 对象节点表示由操作生成或消耗的特定数据或物理实体的实例，使用实例名称 : 类名 约定（例如，一个提案 : 提案 和 一个计划 : 交付项目计划).

  • 明确标记的 创建 箭头精确地显示了操作实例化或更新数据结构的时刻，展示了数据如何在任务之间流动，同时伴随操作的执行。

Activity Diagram, UML Diagrams Example: Relationships between Activates and Business Entities - Visual Paradigm Community Circle

何时使用:

  • 记录业务流程

  • 建模用例实现

  • 指定复杂算法

8. 状态机图（状态图）

目的：建模对象的生命周期和与状态相关的行为。

关键元素:

  • 状态（带入口/出口/执行活动的圆角矩形）

  • 转换（触发条件[守卫]/效果）

  • 伪状态：初始、选择、分叉、汇合、历史、终止

  • 复合状态和正交区域

示例用法：电话系统设置

状态与系统条件

该图通过描绘系统（特别是电话系统设置）的各种离散情况或状态，来捕捉系统的运行行为。

  • 状态： 圆角矩形表示状态（例如，空闲, 拨号音, 拨号中, 连接中，以及已连接）。一个状态表示对象生命周期中的一个阶段，在此阶段中，对象满足某种条件、执行某项活动或等待某个事件。

  • 初始伪状态： 左侧的实心黑圆圈表示状态机的起始点。它是一个伪状态，而非真正的状态，仅作为对象实例化时指向默认活动状态的指针（空闲).

  • 最终状态： 右侧的靶心符号表示状态机执行的终止，表明对象已完成其生命周期。

转换与事件驱动的路由

连接各个状态的有向线段是转换，表示在特定触发条件下从一个状态到另一个状态的转移。

  • 标准转换： 由特定事件触发，例如用户操作或系统响应，这些事件标注在连线之上。例如，从空闲到拨号音发生于挂机事件被触发时，以及从拨号音到拨号中 在一个 digit(n) 事件被接收时发生。

  • 自转换： 一个从状态出发并直接返回到该同一状态的转换箭头（如在 拨号 状态中，由 digit(n) 触发器触发）。这表示事件被处理并更新了内部状态上下文（例如，记录一个新拨出的数字），而不会导致对象退出或改变其整体操作状态。

替代路径与错误处理

状态机擅长展示执行过程中基于不同条件的行为逻辑和错误分支。

  • 成功执行路径： 中心水平流程图描绘了最佳路径：空闲 $rightarrow$ 拨号音 $rightarrow$ 拨号 $rightarrow$ 连接中 $rightarrow$ 振铃 $rightarrow$ 已连接 $rightarrow$ 已断开.

  • 异常和错误处理状态： 系统通过分支进入专用处理状态来应对失败或延迟。如果在连接过程中号码占线，系统将触发 numberBusy 进入的转换忙音 状态。如果用户在拨号时暂停时间过长，一个超时 事件会将系统转移到警告 或超时 状态。如果检测到错误的序列，一个无效号码 触发器会将系统引导至录音消息 状态，确保系统能够安全处理所有现实世界中的边缘情况。

State Diagram - A Quick Tutorial - Visual Paradigm Blog

 

何时使用:

  • 建模嵌入式系统或协议实现

  • 指定用户界面状态管理

  • 记录对象生命周期规则

9. 交互图

四种图类型强调对象协作的不同方面：

a) 顺序图（最常见）

目的：展示生命线之间按时间顺序的消息交换。

关键元素:

  • 生命线（垂直虚线）

  • 消息（带标签的实线/虚线箭头）

  • 执行时段（激活条）

  • 组合片段：alt, opt, loop, par, break

示例用法:

生命线和执行上下文

该图从左到右表示参与者，从上到下表示时间的流逝。

  • 生命线： 顶部连接虚线的方框代表生命线。它们按照以下约定模拟交互中的各个参与者：实例名 : 类名 约定（例如，window : UI, aChain : HotelChain，以及aHotel : Hotel）。虚线跟踪该参与者在整个序列中的存在。

  • 激活条： 位于生命线顶部的细长彩色竖条表示一个激活（或执行发生）。这些条形精确地显示了对象正在执行操作或等待嵌套子调用返回的时刻。

  • 已停止： 在window : UI 生命线表示销毁或终止，表明该特定参与者的生命周期已经结束，其资源已被释放。

消息类型与通信

参与者之间的通信通过水平箭头建模，表示消息，并使用分层编号系统（例如，1、1.1、1.1.1）按顺序排列。

  • 同步消息： 实线配实心箭头（如 1: makeReservation 和 1.1: makeReservation）表示同步调用。发送方会阻塞执行，等待接收对象完成其处理。

  • 自消息： 一个消息循环，从同一激活条开始并结束（例如 1.1.1: available(roomId, date): isRoom 由 aHotel）表示一个 自消息。这表示对象调用自身某个操作的内部方法执行。

  • 创建消息： 一条虚线，带开口箭头，直接指向对象框（例如消息 1.1.2: 指向 aReservation : Reservation）表示对象创建。这表明 aHotel 实例在运行时序列的该时刻动态实例化了 aReservation 对象。

组合片段与控制流

围绕序列部分的大型矩形框是 组合片段，使用交互操作符来管理复杂的逻辑、分支和迭代。

  • 循环片段： 外层框标记为 循环，带有保护条件 [每天] 表示迭代。此框内包含的所有交互将针对预订请求中指定的每一天持续重复。

  • 替代组合片段（Alt）： 嵌套在循环内部的是一个 alt 片段（在图示指针中标注为“如果”），用于处理条件分支。它评估保护条件 [isRoom = true]。如果条件满足，该序列将执行该块内的特定路径——创建 aReservation 实例，并随后触发消息 2: 以实例化 aNotice : 确认。如果条件为假，则会采取替代路径（或不采取任何操作）。

b）通信图

目的：强调对象关系而非消息时序。

What is Communication Diagram?

关键元素:

  • 对象作为节点

  • 带有编号、有方向的消息链接

  • 关注“谁与谁交谈”

c）交互概览图

目的：使用活动图符号表示高层控制流。

Interaction Overview Diagram Example

关键元素:

  • 交互出现作为活动节点

  • 决策/合并用于分支

  • 分叉/合并用于并行

d) 时序图

目的: 建模精确的时序约束（实时系统）。

What is Timing Diagram?

关键元素:

  • 每个生命线的状态时间线

  • 时间尺度和约束

  • 带有持续时间标记的消息箭头

何时使用交互:

  • 指定用例实现

  • 调试复杂的消息流

  • 记录API使用模式

  • 建模实时协议时序

10. 用例图

目的: 从外部参与者视角捕获功能需求。

关键元素:

  • 用例（椭圆或分类器矩形）

  • 参与者（小人图或分类器）

  • 关联（参与者 ↔ 用例）

  • 关系：«include», «扩展»，泛化

  • 系统边界框

示例用法：ATM系统

A Comprehensive Guide to Use Case Modeling - Visual Paradigm Guides

何时使用:

  • 与利益相关者进行需求获取

  • 定义系统范围和边界

  • 规划测试场景

🎯 选择正确图表：决策指南

目标 推荐图表
设计类结构 类、对象、包
建模运行时交互 顺序图、通信图
记录业务流程 活动图、用例图
指定对象生命周期 状态机
规划系统部署 部署图、组件图
建模复杂的内部结构 组合结构图
捕捉实时约束 时序图
定义需求 用例图、活动图

🔑 关键建模原则

  1. 从简单开始: 从最符合你当前目标的图表类型开始。

  2. 迭代: 随着理解的加深不断优化模型——第一稿的任何图表都不是“最终版”。

  3. 受众很重要: 根据读者（开发者与利益相关者）调整细节程度。

  4. 结合视图: 使用多个图表来讲述一个完整的故事（例如：用例 → 顺序图 → 类图）。

  5. 谨慎扩展: 为特定领域需求使用构造型、标记值和配置文件，但要记录下约定规范。

  6. 保持可读性: 省略无关细节；使用注释提供补充上下文。

📌 记住: “UML 是一种语言，而不是一种方法论。” 它提供的是符号表示，而非流程。选择能澄清沟通的图表，而不是为了填勾选框而选的图表。

结论

掌握UML的关键不在于记忆每一个语法规则，而在于学会清晰、有目的性地讲述关于你系统的完整故事。正如本指南所示，每种UML图表类型都提供了独特的视角：类图和包图揭示静态架构，顺序图和状态机图展现动态行为，而部署图和复合结构图则连接了设计与执行。UML真正的力量在于其适应性——它可以从白板草图扩展到工具驱动的可执行模型，并能适应开发者、架构师和业务利益相关者的需求。请记住，有效的建模是迭代的、以受众为导向的，并且有意识地选择性。从最简单的、能传达你意图的图表开始，随着理解的加深不断优化，并在单一图表无法充分表达时结合多个视图。UML是一种沟通语言，而非合规检查清单；应使用它来澄清模糊，而非制造模糊。通过有意识地应用这些原则，你将能把抽象概念转化为可执行的蓝图，使团队保持一致，加速开发进程，并确保系统在演进过程中依然保持韧性。