架构师 - 3.UML

UML建模

标签：UML 统一建模语言 软件架构建模 4+1视图

UML（Unified Modeling Language，统一建模语言）的图有十几种，逐个记忆容易混淆。可以按一条主线、两个维度、三大构成、4+1 视图、从需求到部署的框架把它们组织起来。

本文以一个电商下单场景为例，把每种图放在它真正被使用的位置上。

---

一、总逻辑链

需求驱动 → 多视图建模 → 静态结构 + 动态行为 → 组件实现 → 部署落地 → 架构验证

在实际项目中，建模顺序与上面的链路一致：先明确系统为谁提供什么功能，再定义内部结构，接着描述运行时的行为和交互，最后落到代码单元和物理节点。每个阶段使用不同的 UML（Unified Modeling Language，统一建模语言）图。

---

二、两个维度：静态 vs 动态

所有 UML 图都可以先归入两个维度：

维度	关注点	典型 UML 图
静态结构	系统由什么组成，彼此是什么关系	类图、对象图、包图、组件图、部署图、组合结构图、制品图
动态行为	系统如何运行、如何交互、如何变化	用例图、活动图、状态机图、序列图、通信图、交互概览图、定时图

工程实践中最常用的十种图：用例图、类图、对象图、包图、组件图、部署图、状态图、活动图、序列图、通信图。

---

三、三大构成：事物—关系—图

UML 的底层逻辑由三层结构组成：

1. 事物：类、接口、用例、组件、节点、状态、交互等。
2. 关系：依赖、关联、聚合、组合、泛化、实现。
3. 图：把事物和关系按不同视角组织起来。

3.1 类图中的六种关系

图 1：类图中的六种关系

在电商场景中的对应：

• 依赖：OrderService 的方法参数中用到 PayRequest，用完即弃；
• 关联：Order 持有 Customer 引用；
• 聚合：Cart 包含多个 Product，商品本身可以独立存在；
• 组合：Order 包含多个 OrderItem，订单取消后明细随之失效；
• 泛化：AlipayPayment 继承抽象基类 Payment；
• 实现：AlipayPayment 实现 Payable 接口。

3.2 用例图中的三种关系

• 包含 <<include>>：基用例必须执行被包含用例。例如"提交订单"必须包含"校验库存"。
• 扩展 <<extend>>：在特定扩展点增强基用例，处理可选或异常流程。例如"使用优惠券"扩展"提交订单"。
• 泛化：特殊用例继承一般用例。例如"微信支付"泛化自"发起支付"。

---

四、架构设计4+1视图与 UML 图映射

架构描述通常采用 4+1 视图模型，每个视图面向不同的关注点：

视图	回答什么问题	常用 UML 图
用例/场景视图	系统为谁做什么	用例图、活动图、序列图
逻辑视图	系统内部的概念结构	类图、对象图、包图、状态图
进程视图	并发、同步、性能、线程	状态图、活动图、序列图、通信图
实现/开发视图	代码和模块如何组织	包图、组件图
部署/物理视图	软件部署到哪些节点	部署图

五个视图的分工：用例视图贯穿需求，逻辑视图承上启下，进程视图关注运行，实现视图关注模块，部署视图关注物理落地。

---

五、从需求到部署：一个电商案例

5.1 需求分析：确定边界与参与者

用例图确定系统边界和外部参与者。电商下单场景的参与者包括：顾客、库存系统、支付网关、物流系统。

主要用例：浏览商品、加入购物车、提交订单、发起支付、查询订单、取消订单。用例之间的关系包括 <<include>> 校验库存、<<extend>> 使用优惠券。

业务流程用活动图描述：活动图可以画出"顾客、订单服务、库存服务"三条泳道，以及"支付超时""库存不足"等分支。

5.2 领域分析：确定静态结构

类图识别系统中的实体、属性、操作和关系：

图 2：下单场景的领域类图

图中体现了三类关系：Order 与 OrderItem 是组合关系（实心菱形，明细与订单同生命周期），Customer 与 Order 是一对多关联，Order 依赖 Payment 完成付款。

对象图表示系统在某一时刻的实例快照。例如订单实例 SO20260918001 与其两条明细构成的对象结构，就是图 2 类图在运行时的一次具体化。

5.3 动态设计：描述交互与状态

序列图按时间顺序展示一次下单过程中的消息传递：

图 3：下单流程的序列图

序列图强调时间顺序。若把同样的交互改为强调对象之间的结构协作，则使用通信图——两者表达的内容等价，可以互相转换。

订单对象在生命周期内的状态变化用状态图描述：

图 4：订单对象的状态图

5.4 模块设计与部署

包图按职责组织代码：order 包、payment 包、inventory 包，order 依赖 payment 和 inventory，依赖方向需要避免出现循环。

组件图描述可替换的软件单元及其接口：PaymentComponent 对外提供 Payable 接口，具体实现可以替换为支付宝组件或微信支付组件。

部署图描述运行时的物理节点与通信路径：

图 5：下单系统的部署图

5.5 用已有模型验证架构

前面建立的图可以直接用于质量属性分析：

• 用序列图检查关键场景的调用链长度与耗时瓶颈；
• 用部署图分析可用性（节点冗余）与安全性（网络隔离、加密链路）；
• 用包图和组件图评估可修改性（替换支付组件时的影响范围）；
• 用状态图检查异常路径是否有出口（例如支付超时是否能正确回到可取消状态）。

---

六、易混图的区分

• 状态图 vs 活动图：状态图描述单个对象在生命周期内因事件触发的状态迁移；活动图描述流程和用例实现，可含泳道、并发与分支。
• 序列图 vs 通信图：两者可相互转换。序列图强调时间顺序；通信图强调对象之间的结构关系。
• 组件图 vs 部署图：组件图描述软件模块及其接口；部署图描述节点、构件实例和物理部署。
• 类图 vs 对象图：类图是模板；对象图是运行时某一时刻的实例。
• 包图 vs 组件图：包图偏逻辑组织；组件图偏实现和接口契约。

---

七、建模时的通用步骤

拿到一个待建模的系统，可以按以下顺序推进：

1. 定视图：先判断当前处在需求、逻辑、进程、实现还是部署阶段。
2. 选图：外部功能选用例图；流程选活动图；对象生命周期选状态图；静态结构选类图；对象交互选序列图或通信图；模块划分选组件图；物理落地选部署图。
3. 列元素：参与者、用例、类、接口、组件、节点、状态、消息。
4. 标关系：include/extend、依赖、关联、聚合、组合、泛化、实现。
5. 对照质量属性：性能看进程视图与部署视图，可修改性看包图与组件图，安全性看部署视图与组件接口，可用性看部署冗余。

---

八、UML 与架构设计、设计模式的关系

UML、架构设计、设计模式经常被放在一起讨论，但它们并不在同一个层面上：

维度	架构设计	设计模式	UML
层次	系统级、子系统级、组件级	类、对象、模块、框架内部	语言层（图纸）
范围	全局结构	局部问题	表达能力本身，无作用范围
关注点	组件划分、交互、部署、技术选型、质量属性、约束、演进	复用、解耦、扩展、职责分配、对象协作	把架构和设计画清楚、说明白
抽象级别	高层、战略级	中层、战术级	表达工具

一句话概括：架构设计是战略层，设计模式是战术（套路）层，UML 是图纸（表达语言）层。

8.1 UML 用于架构设计

架构设计的骨架是 4+1 视图，UML 是把它画出来的语言。前面已经按"视图 → 用哪些图"梳理过一轮，这里换个方向，看每种图在架构中承担什么职责：

• 用例图：确定系统边界与外部参与者，是所有视图的组织者；
• 包图：划分逻辑模块，控制依赖方向，避免循环依赖；
• 组件图：定义可替换的软件单元与接口契约；
• 部署图：描述节点、构件实例、通信协议与物理落地；
• 序列图：刻画关键场景的调用链，用于验证性能、可用性等质量属性。

需要注意这里的层次：4+1 视图是架构设计的骨架，上面这些 UML 图只是表达骨架的语言；至于类图内部"该用哪个设计模式"，已经属于战术层问题。

8.2 UML 用于设计模式

设计模式本身不依赖 UML，但 UML 是描述模式最通用的方式：

• 类图描述模式的静态结构：参与者角色及其依赖、关联、泛化、实现关系；
• 序列图描述对象协作：运行时的消息顺序与调用次序；
• 状态图描述状态变化：对象在生命周期内因事件触发的迁移。

以本文的电商案例举例：

• 策略模式：Payment 抽象基类与 Payable 接口是类图上的静态结构；运行时"选支付宝还是微信支付"的决策过程，用序列图或对象图表达；
• 观察者模式：订单状态变更后通知库存、物流，体现在类图的依赖关系与序列图的消息广播上；
• 状态模式：订单状态图本身就是状态模式的雏形，每个状态可以对应一个可替换的实现类。

需要注意：UML 只能画出模式的结构和协作，画不出"为什么这里该用这个模式"。

按模式类别速查该用哪种图：

模式类别	首选图	补充图	典型模式
创建型	类图	序列图（创建流程）、对象图	单例、工厂方法、抽象工厂、建造者、原型
结构型	类图	对象图（运行时的组合结构）	适配器、装饰器、代理、组合、桥接、外观、享元
行为型	序列图（或通信图）	类图（角色关系）、状态图	观察者、策略、命令、模板方法、责任链、状态、访问者

实践中最常用的组合是类图 + 序列图：类图定静态结构，序列图定运行时时序；状态模式额外配一张状态图；结构型模式若要强调"运行时对象是怎么拼起来的"，再补一张对象图。

8.3 UML 只是表达工具

1. 它不告诉你"应该怎么架构"：架构决策来自质量属性权衡、业务约束和工程经验，UML 只是把决策结果记录下来；
2. 它不告诉你"该用哪个模式"：模式选择来自对变化点和复用性的判断，而不是图怎么画；
3. 它的核心价值是减少歧义：让需求方、架构师、开发对同一张图有一致的理解，图本身不产生设计，只承载和校验设计。

因此正确的顺序是：先做架构决策与模式选择，再用 UML 表达、评审、验证。图与实际不一致时要改，但图不是设计的来源。

---

九、总结

用例驱动需求，类图承载结构，交互/状态/活动描述行为，包图和组件图组织实现，部署图完成落地，4+1 视图把 UML 图组织成一份完整的架构描述。

串联口诀：

外用例，内类图；静结构，动交互；流程活动，一生状态；实现组件，落地部署；逻辑进程开发物理，场景贯穿 4+1。