使用 PlantUML 进行数据建模的 UML 类图

一个UML 类图描述了结构：它所建模的事物、这些事物的属性以及它们之间的关系。对于数据建模而言，它可以在您确定表结构或编写应用程序代码之前，捕捉领域概念和约束条件。

PlantUML使图表可复现：您编写文本、将其渲染、在版本控制中审查更改，并随着模型的演进进行更新。它是对数据库模式、迁移和详细业务规则的补充，而非替代。

1. 选择建模层级

一个有用的数据建模图通常一次专注于一个层级：

• 概念层：业务概念及其关系，技术细节极少。示例：客户下订单.

• 逻辑层：属性、标识符、基数和规则，且不将模型绑定到特定数据库。

• 物理层：实现细节，例如 SQL 列类型、索引和数据库特定约束。

下面的示例是一个逻辑领域模型。诸如UUID, Money和DateTime仅为示例；在选择技术时再决定其具体表示形式。

2. PlantUML 基础

类具有名称，并可列出属性和操作：

@startuml
class Customer {
  -id: UUID
  +name: String
  +email: String
  +changeEmail(newEmail: String): void
}
@enduml

可见性标记是可选的建模提示：

• + public

• - private

• # protected

• ~包可见性

对于领域图或数据图，属性最为重要。仅在操作能阐明重要行为时才包含它们；避免将图表变成完整的代码列表。

3. 关系与多重性

数据建模中最有用的关系表示法包括：

多重性标签位于关联端附近：

• 1 — 恰好一个

• 0..1 — 可选，最多一个

• * 或 0..* — 零个或多个

• 1..* — 一个或多个

• 2..5 — 有界范围

例如：

Customer "1" -- "0..*" Order : places

仔细阅读两端的标签：一个客户可以下零个或多个订单；每个订单仅与一个客户关联。这些标签描述的是关系，而不一定是特定数据库中外键的实现方式。

4. 示例：在线商店

该模型包含客户、订单、订单项、产品和支付记录。它展示了标识符、值类型、枚举、组合关系以及多重性。

@startuml ShopDomain
skinparam classAttributeIconSize 0
skinparam shadowing false

hide methods

class Customer {
  +customerId: UUID
  +email: EmailAddress
  +displayName: String
}

class Order {
  +orderId: UUID
  +placedAt: DateTime
  +status: OrderStatus
  +total: Money
}

class OrderLine {
  +lineNumber: Integer
  +quantity: PositiveInteger
  +unitPrice: Money
}

class Product {
  +productId: UUID
  +sku: SKU
  +name: String
  +currentPrice: Money
}

class Payment {
  +paymentId: UUID
  +amount: Money
  +status: PaymentStatus
  +paidAt: DateTime [0..1]
}

class Money <<value object>> {
  +amount: Decimal
  +currency: CurrencyCode
}

enum OrderStatus {
  DRAFT
  PLACED
  PAID
  FULFILLED
  CANCELLED
}

enum PaymentStatus {
  PENDING
  AUTHORIZED
  CAPTURED
  FAILED
  REFUNDED
}

Customer "1" -- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
OrderLine "0..*" --> "1" Product : refers to
Order "1" -- "0..*" Payment : payment attempts
Order --> OrderStatus
Payment --> PaymentStatus
OrderLine --> Money : unit price
Payment --> Money : amount

note right of OrderLine
  quantity must be greater than zero
  unitPrice is the price captured
  when the order is placed
end note

note right of Product
  Product.currentPrice may change.
  It does not replace OrderLine.unitPrice.
end note
@enduml

为什么要建模订单项显式地？订单与产品之间的关系拥有自己的数据——数量和购买时的价格。这使其成为一个领域概念，而不仅仅是一条普通的链接。

为什么从订单到订单项?该示例假设订单项属于一个订单，且不具有独立意义。仅当您的领域中确实存在这种所有权和生命周期规则时，才使用组合关系；UML 符号本身不会在数据库中强制执行这一规则。

为什么要区分当前价格和历史价格？产品的价格可能在订单下达后发生变化。在订单项中保留购买时的价格，可以保留历史金额。

5. 重要的建模决策

标识符：始终如一地标记标识符，例如customerId或orderIdUML 未定义主键的单一通用表示法，因此请选择一种约定并加以文档化。可以使用构造型或注释使其明确：

class Customer {
  +customerId: UUID <<PK>>
  +email: EmailAddress
}

可选值： 使用 [0..1] 表示可选属性，当这对读者而言显而易见时，或注明该规则。例如，一笔付款在成功之前可能没有 paidAt 时间戳，直到付款成功为止。

值对象： 如 Money 或 EmailAddress 可表示具有自身验证规则或语义的概念。应根据受众和详细程度，决定其应表现为独立类、属性类型还是数据库结构。

枚举和受控值： 当允许的值集合较小且相对稳定时，使用枚举。如果值需要独立的描述、生命周期或管理，则应将其建模为类。

规范化与实现： 类图用于传达概念和规则，但不会确定所有关系细节。例如，Money 是变为两列、独立表还是数据库特定类型，属于实现决策。

保持图表可读性： 将大型领域拆分为聚焦的图表，例如订单、库存和身份，并使用包来分组相关类。仅显示与图表旨在回答的问题相关的属性。

6. 根据需求构建模型

1. 提取候选概念从领域语言中：名词通常暗示类；动词通常暗示关系或行为。

2. 明确规则通过具体问题：订单能否在没有客户的情况下存在？能否包含零行？支付能否重试？

3. 选择建模层级并将技术数据库决策排除在概念图之外。

4. 添加属性和标识符仅在它们有助于解释模型时添加。

5. 设置多重性从业务规则中推导，并检查每个关系的两端。

6. 审查边界情况：删除、历史记录、可选字段、重复尝试以及值变更。

7. 渲染并审查与领域专家和实施人员一起审查该图。将其视为需要验证的模型，而不仅仅是需要批准的图片。

7. 使用 VPasCode 和 Visual Paradigm

VPasCode是一个基于浏览器的支持 PlantUML 的文本转图表编辑器并提供实时预览。其功能描述还列出了图表代码的 AI 生成与修改，以及语法辅助功能。一个实用的工作流程如下：

1. 打开 VPasCode 并选择或输入 PlantUML。

2. 粘贴上述示例并检查渲染后的图表。

3. 迭代 PlantUML 源代码；将文本作为可版本化的工件保留。

4. 如果工作区中有 AI 助手可用，请使用它来起草或修订初稿。

5. 亲自验证每个生成的类、关系、多重性和业务规则。

Visual Paradigm 的 AI 辅助图表工具可以根据自然语言描述生成可编辑的图表。其发布的流程描述了从提示生成类图，然后细化其元素和关系。将 AI 输出视为草稿：它可能会推断出错误的归属、缺失的约束或不合理的类。模型的正确性仍然取决于将其与需求进行验证。

例如，向 AI 助手提出以下提示：

为在线商店创建一个逻辑 UML 类图。客户下订单。每个订单包含一个或多个订单项。每个订单项引用一个产品，并存储数量和购买时的单价。订单可以有多个支付尝试。包含标识符、多重性以及订单和支付状态枚举。仅输出 PlantUML。

然后在接受之前，对照需求审查输出结果。为了获得更好的结果，请明确指定假设——例如，订单是否可以是没有行的草稿，以及支付是否可以退款。

Visual Paradigm 描述VPasCode 作为 支持 PlantUML 的编辑器 具备实时渲染和 AI 辅助生成或修改。工具和可用性可能因产品版本或工作区而异。

8. 精简的审查清单

在共享或实现类图之前，请检查：

• 每个类是否代表有意义的领域概念？

• 标识符和重要属性是否清晰？

• 关系标签和多重性在 两端 是否正确？

• 组合是否反映了真实的生命周期依赖关系？

• 在值可能变化的地方，是否保留了历史事实？

• 可选值和业务约束是否可见？

• 该图是否足够聚焦于其受众？

• 生成的内容是否已与实际需求进行核对？

最佳的图即代码工作流是 AI 用于生成初始草稿，PlantUML 用于精确编辑和版本历史，人工审查用于确保领域正确性.