《Visual Paradigm 与 VPasCode 实用 UML 指南》

统一建模语言（UML）是一种标准化的方式来描述系统的结构和行为。它帮助团队讨论需求、设计软件并记录决策。UML 是一种建模语言，而非编程语言：图表用于传达模型，但并不能自动保证实现与模型一致。

本指南以在线购物系统作为贯穿始终的示例。它涵盖了主要的 UML 图表类型，并介绍了使用Visual Paradigm进行可视化建模，以及使用VPasCode进行基于文本的图表绘制。

1. 从图表应回答的问题开始

在绘制之前，先确定读者需要理解的内容：

• 用户能做什么？使用用例图。

• 在某个场景中会发生什么？使用序列图或活动图。

• 哪些概念和关系构成了该领域？使用类图。

• 软件如何划分为可部署或可替换的部分？使用组件图和部署图。

• 一个对象如何随时间变化？使用状态机图。

试图一次性回答所有问题的图表通常难以阅读。应优先选择多个专注的图表，而非一个拥挤的总览图。

2. UML 图表家族

UML 2.x 包含 14 种标准图表类型，通常分为结构图和行为图。交互图是行为图的一个子集。

一个项目很少需要全部 14 种图。对于许多应用设计，用例图、类图、序列图、活动图、组件图和部署图是一个强有力的起始集合。

3. 最实用的图表，附带电子商务示例

用例图：目标与系统边界

用例图描述用户目标，而非屏幕布局或内部代码。对于在线商店，参与者可能包括顾客, 支付提供商，以及仓库服务。用例可能包括浏览商品, 下订单, 支付订单，以及追踪发货.

使用<<包含>>，当用例始终调用另一个必需行为时。使用<<扩展>>，用于可选或条件行为，这些行为为基本用例增添功能。保持系统边界清晰，以便读者能够区分系统与外部参与者。

活动图：工作流与决策

活动图适用于具有分支或并行工作的流程。结账流程可能如下：

1. 验证购物车和地址。

2. 计算运费和税费。

3. 创建待处理订单。

4. 请求支付授权。

5. 如果支付成功，确认订单并通知履约。

6. 如果支付失败，显示失败信息并保留订单为未确认状态。

使用决策节点和合并节点处理分支，使用分叉节点和连接节点处理并行工作，并在客户、商店和外部提供商之间责任发生变化时使用泳道。

序列图：随时间推移的单一场景

序列图展示参与者及其交换的消息。它们特别有助于明确服务边界、调用顺序和错误情况。为支付被拒或库存不可用等情况添加替代路径。

@startuml
actor Customer
participant "Storefront" as UI
participant "Order Service" as Orders
participant "Inventory Service" as Inventory
participant "Payment Provider" as Payment

Customer -> UI: 提交结账
UI -> Orders: 下订单(cart, address)
Orders -> Inventory: 预留商品(items)

alt 商品可用
    Inventory --> Orders: 预留确认
    Orders -> Payment: 授权(total)
    alt 支付批准
        Payment --> Orders: 批准
        Orders --> UI: 订单确认
        UI --> Customer: 显示确认
    else 支付被拒
        Payment --> Orders: 被拒
        Orders -> Inventory: 释放预留
        Orders --> UI: 支付失败
        UI --> Customer: 显示支付错误
    end
else 商品不可用
    Inventory --> Orders: 预留失败
    Orders --> UI: 商品不可用
    UI --> Customer: 显示可用性错误
end
@enduml

此示例使用 PlantUML 语法。它是一个行为草图，并非对每个超时、重试或安全规则的详细规范。当这些细节对设计至关重要时再添加。

类图：领域结构

类图描述类型及其关系。一个简单的订单模型可能包含：

• 客户

• 订单

• 订单项

• 商品

• 支付

当有助于解释职责时，显示属性和操作。使用多重性使数量规则明确：例如，一个订单包含一个或多个订单项对象，而每个订单项引用一个产品.

常见关系类型：

• 关联：一种通用的结构链接。

• 继承/泛化：一个类是另一个类的特化类型。

• 聚合：一种整体与部分的关系，其中部分可以独立存在；应谨慎使用。

• 组合：一种强整体与部分的关系，其中部分的生命周期与整体绑定。

• 依赖：一个元素使用或依赖于另一个元素。

对于商业模型，一个订单项通常被建模为属于一个订单，而一个产品独立于任何特定订单存在。请选择能反映领域实际生命周期和规则的关系。

状态机图：生命周期规则

当对象的允许转换至关重要时，请使用状态机。订单可能经历以下状态：

待处理 → 等待支付 → 已确认 → 已履行

它也可能转换到已取消或支付失败。用触发事件或守卫条件标记转换，例如paymentApproved或[库存可用]. 此图可揭示无效的状态转换——例如，已完成的订单是否可以被取消。

组件图与部署图：软件与运行时环境

一个组件图展示软件职责与依赖关系，例如 storefront（前端商店）、订单服务、库存服务和支付适配器。它有助于讨论模块化和集成边界。

一个部署图展示软件运行位置：例如浏览器、应用运行时、数据库和外部支付提供商。用于讨论运行时拓扑结构，而非详细的网络配置。

4. 良好建模：实用规范

• 为每张图赋予清晰的标题和单一目的。

• 始终如一地使用领域语言；避免为同一概念发明不同的名称。

• 保持图表足够小，以便在其预期尺寸下可读。

• 仅包含能够回答该图所提问题的细节。

• 标注重要的关联关系和消息流。

• 当数量规则重要时，为关联关系添加多重性。

• 使用注释说明假设、约束和未决决策。

• 确保不同图表中的名称和职责保持一致。

• 区分已确认的内容与提议中或尚不明确的内容。

• 当重要设计决策或行为发生变化时，及时更新图表。

将 UML 视为沟通辅助工具。即使语法正确，若标签、假设或范围不清晰，图表仍可能产生误导。

5. 使用 Visual Paradigm

Visual Paradigm 适用于图形化建模：在画布上创建和排列 UML 元素，组织相关图表，并通过可视化编辑完善模型。其产品资料将 UML 建模列为其可视化建模能力之一。

一个实用工作流程：

1. 创建一个项目用于你所建模的系统或限定范围。

2. 从需求和范围开始。识别用户、外部系统和关键目标。

3. 创建一个用例图以明确边界和主要交互。

4. 添加行为图针对风险或歧义最大的场景。

5. 构建类模型围绕领域概念及其规则。

6. 添加组件和部署视图如果架构或运行时部署需要讨论。

7. 与利益相关者进行评审。检查名称、范围、备选流程和基数。

8. 导出或共享图采用适合评审和文档的格式。

9. 保持模型的维护。指定负责人，并在决策变更时更新图。

确切的菜单名称和可用功能可能因 Visual Paradigm 的版本和发布而异，因此请使用该产品当前的界面文档以获取特定版本的步骤。

6. 使用 VPasCode

VPasCode 是 Visual Paradigm 提供的一款基于浏览器的“图即代码”编辑器。其产品说明描述了支持基于文本的图格式（包括 PlantUML 和 Mermaid），并支持实时渲染；同时它还支持导出为 SVG 和 PNG 等格式。

一个简单的工作流程：

1. 打开 VPasCode 并选择图语言，例如 PlantUML。

2. 编写或粘贴图脚本。

3. 在编辑时查看渲染后的预览。

4. 优化名称、关系、布局和错误路径。

5. 导出图像以用于文档或评审。

6. 如果您希望保留可评审和版本控制的基于文本的记录，请将源脚本与项目一起保存。

VPasCode 非常适合快速草稿、文档图以及偏好基于文本编辑的团队。Visual Paradigm 的图形模型在需要以可视化方式操作模型元素并将图作为更大建模项目的一部分进行组织时非常有用。这两种方法可以相互补充，但不应假设每个图或模型都能在两者之间完美地双向转换；请在您的工作流程中验证任何转换。

7. 一个有用的端到端工作流程

对于结账功能，一个轻量级的建模序列可能如下：

1. 用例：定义谁可以下订单，以及哪些外部系统参与。

2. 活动：映射结账流程及其决策。

3. 序列：详细说明成功、支付失败和库存不可用路径的交互。

4. 类：定义订单、订单项、产品和支付概念及其规则。

5. 状态机：指定有效的订单生命周期。

6. 组件：展示哪些服务负责这些职责。

7. 部署：如果基础设施决策相关，则记录运行时部署位置。

当团队受益于基于画布的建模和受管理的可视化模型时，请使用 Visual Paradigm。当团队希望快速编写和渲染图表文本时，请使用 VPasCode。一种常见的方法是在 VPasCode 中起草场景，与团队一起审查并完善它，然后以最适合项目文档和变更流程的格式维护图表。

8. 常见陷阱

• 试图一次性绘制整个系统：按关注点或场景进行拆分。

• 混淆活动与序列：活动强调工作流；序列强调随时间推移的消息。

• 类图过载：关注相关的领域概念，而非每一个实现细节。

• 使用包含和扩展作为装饰：它们表达用例之间的特定关系。

• 遗漏备选路径：失败和取消往往能揭示重要需求。

• 将图表视为规范：明确记录重要的业务规则、假设和约束。

• 任由图表过时：过时的图表可能比没有图表更糟糕，因为读者可能会信任它。

强大的 UML 集并非最大的集合。它是最小的图表集合，能让目标读者理解系统、讨论决策，并在问题变得昂贵之前发现差距。